Show HN: PDF API – Generate, convert, and modify PDF documents
Arek here. We’re super excited to officially launch PSPDFKit API [1].
PSPDFKit API is a collection of HTTP APIs that enable you to convert, generate, and edit documents without running any service on your infrastructure.
What differentiates our API from others is that you can chain together multiple “actions” as part of a single API request. For example, you can convert, OCR, watermark, edit, and flatten a document — all in one call.
Available actions [2]:
- PDF Generator
- PDF Converter
- Image Converter
- OCR
- Watermark
- Merge
- Split
- Duplicate
- Delete
- Flatten
Our documentation includes sample code for JavaScript [3], Python [4], Java [5], C# [6], PHP [7], and the command line. We also have a Postman collection [8].
Let us know what you think or if you have any questions.
[2] https://pspdfkit.com/api/documentation/tools-and-api/
[3] https://pspdfkit.com/api/tools/javascript/
[4] https://pspdfkit.com/api/tools/python/
[5] https://pspdfkit.com/api/tools/java/
[6] https://pspdfkit.com/api/tools/csharp/
[7] https://pspdfkit.com/api/tools/php/
[8] https://pspdfkit.com/api/documentation/getting-started/postm...
124 comments
[ 3.5 ms ] story [ 181 ms ] threadConsider perhaps adding one more call, one to remove passwords. Not brute force, although that would be cool too, but just one that let's you specify the password and it makes the pdf no longer require a password.
Files for printing production need to have their fonts embedded, color profiles attached/at least tagged to images, transparency dealt with, lots of stuff that ensures that the PDF itself contains all the necessary information for a successful reproducting/printing on a printing machine of any kind.
As printing production systems have evolved, the rules became "less strict" as all (most) the systems can now handle transparency natively, for example. That for example was a big change with PDF/X4, before you had to convert (keyword is "transparency reduction") all transparencies and factor them into the underlying elements.
Most PDF generators out there are not able to follow the rules of ISO/the PDF/X specifications, so print shops might have a hard time handling that data, due to various missing pieces of information.
That's normally no deal for your office printer, but when you are looking at large(r) printing operations, it surely is.
[1] https://en.wikipedia.org/wiki/PDF/X
> Most PDF generators out there are not able ...
Do you know of any compatible?
The one is PDFlib [1] which can easily be accessed via Java and PHP. As a web guy, I'm using PHP obviously. There's some learning curve to it, and you have to take care of lots of stuff by yourself, but the results are pretty good afterwards.
The second are the products from callas, mainly pdfToolbox [2] and pdfChip [3], which are kind of the de facto standard for the printing industry, at least in my Western Europe bubble.
pdfChip is based around the WebKit rendering engine, so you can work with HTML + CSS and convert your document to a PDF file. The pdfChip internals will take care of PDF/X compliance, if you want to.
pdfToolbox and pdfChip both have a steep learning curve, too, but you'll probably find that with any software that is highly specialized.
[1] https://www.pdflib.com/ [2] https://www.callassoftware.com/en/products/pdftoolbox [3] https://www.callassoftware.com/en/products/pdfchip
Quite expensive though. When I use an API, I usually assume (1) there will be some significant base volume, and (2) this volume has no upper bound, depending on my users behavior. For ~750 € you can only process 1k documents during the month... hard-capped? The price schemes seem to target entreprise but entreprises usually have bigger volumes than that. (But maybe I confuse API calls and document processing with your product?)
But it’s nice you released SDK in several common languages.
Good luck!
At this point in time the price is per generated document - irrespectively of how complicated the operation is.
Because you can combine operations in one http call, you're incentivised to do that as opposed to perform separate calls which increase the possibility of errors and cost for all sides.
Happily taking feedback though - your comment around hard-cap is definitely sound, for example.
As part of an integration for a few customers we do relatively simple PDF operations. Combining a few TIFFs into a PDF, or splitting a PDF into separate PDF per page for example. Think invoices vs orders. Can be a royal PITA though due to edge cases in terms of whatever generated the TIFFs or PDFs.
However each of our customers have 1-10k documents per day, and we're in Scandinavia so small fries in terms of volume.
edit: OCR and table extraction is something that might be very interesting depending on quality, but again even 10k/mo seems low for most of our larger customers.
Source: I work at PDF Blocks
Also, it’s a Show HN.
Seems reasonable to share alternatives.
I’ve been looking for an easy OCR solution considering I have about 10,000 one-page documents a month (invoices). For comparison, Amazon textract is ~$0.05/pg for key-value pairs, but it involves more programming to set up.
[0]: https://www.fintract.io/en/
Or filling out pdfs programmatically (a docspring alternative)?
Filling out forms is not supported, but I'll take a note. The engine can do it, but we haven't got it exposed via the API.
* (becomes harder when the font is not embedded/existent as a subset, but Acrobat let's you choose another font, so no big deal.)
Sometimes text is positioned absolute to the page border, sometimes relative to other elements, where moving a word shifts all following elements around. There can be multiple matrices involved for positioning text elements. Sometimes text elements are all positioned independently, sometimes by using newlines with custom size. Text elements can span multiple lines or words but sometimes each letter is a single text element where it is even hard to determine, which letters go together or if there's meant to be a space. Additionally fonts can be subsetted, where it's impossible to use other unused letters without knowing the original font. And than there can be OCR'ed PDF's, where an image of scanned text is overlayed on top of the real text. Oh and there can be clipping paths: Rectangles which erase all text below.
And each PDF-Producer creates a different PDF structure.
For reading, PDF's are awesome. For editing, PDF's are a nightmare.
Question: do you have or plan to support PDF signatures? This may be then useful for us[1], we issue qualified certificates and eIDAS-compliant legal qualified electronic signatures which often need to then be embedded into PDFs.
[1]: https://www.zealid.com/en/
[1] https://pspdfkit.com/server/processor/
Sounds to me like an unnecessary extra expense for an unnecessary extra layer of abstraction. And there's a risk factor that comes with it: Say I make a nontrivial investment, like write a book that I'm planning on typesetting with this, or write a reporting infrastructure that creates automated reports or something. I'll make a huge up-front investment there that is tied to your API. Then I want to run this, while not touching it, for 10 years so it can earn a return on investment.
Then I come back to it 10 years later, because I'm writing the second edition of the book, or I want to change something about my reporting infrastructure. Has your company gone out of business in the meantime? Have you deprecated the product? Do you still support the API from 10 years ago? Does it still produce the same output for the same input? ...or do I need to take a huge write-off on all the work I've done on the typesetting my book or hooking up my reporting infrastructure?
In the open source world, I'd just make sure to bundle all the tools I'm using, including their sourcecode, in a docker container or something. In the "10 years later" scenario, I'll probably need to touch only the book's sourecode, or the reporting infrastructure's sourcecode, not the typesetting infrastructure. And if there's something I really really need, then I can go to the source and change it.
I once worked for a software company where non-tech clients would have custom-made software developed for their exclusive use. Half the projects we did were "We're relying for one of our business functions on this software that we bought from this company that's now out of business. We need you to reimplement it from scratch, because we need a tiny change."
- We do build on top OSS (just not those programs you listed - see https://pspdfkit.com/legal/acknowledgements/processor-acknow... for a complete list). The layer we build is quite large though, and it would take many person-years to replicate in its entirety. It’s possible though that you don’t need that at all and a focused program that wraps other ones might do the trick for your use case.
- If you build a product based on our tech, you’re taking a conscious decision about risk: while I do think we’re gonna be in business in 10 years (we have solid revenue and last year we got backed by a large investor, Insight), that we would version APIs and support you (not just during upgrades), the reality is that it is indeed possible that we’re not gonna be around anymore, like every other company on the planet. As a consumer, this is the reality for most of the things we buy nowadays. We do take deprecation seriously, as sell SDKs, and I’m sure in case of the company shutting down you would have enough time to migrate.
- Depending on what you need to build, using our product may shortcut your development time by a large factor. It may not, if you just need to rotate pages of a PDF document and there’s a reliable OSS package that does that in your language of choice. It really depends on what you need to do.
- Even if you package everything with OSS, waiting 10 years is a sufficiently large amount of time that it may not work and you have to fork and rebuild yourself. It’s a different type of risk, but still a risk. 10 years ago Docker had just been launched. Whether you build something on OSS or commercial, you would wanna test things once a year to see if they still work or keep up with security and bug fixes.
Ultimately, there are situations where the approach you described is sound: for example, I do my taxes in plain text accounting, using ledger and emacs. I generate the reporting via a couple of Ruby scripts. I do that exactly because I care about longevity: I do my taxes once a year, I don’t wanna spend time fixing the toolchain every time I have to do them. Yet every year I hit a couple of snags I have to fix, but I consider that acceptable.
Those seem like one-off PDF conversion use cases that MS Word or Acrobat can easily handle. Not a high-volume, daily PDF invoice use case.
Most organizations these days are developing in the cloud. I assume you don't mean "offline" but rather performing these functions yourself.
I've tried, but it's a huge pain in the butt. PDFs are very quirky. Things work well 95% of the time and the 5% takes a lot of time to figure out.
When trying to do this myself in an app deployed to AWS, I've had many issues with getting all characters in different languages to work. Every few months, some new thing in a PDF file throws an error and the file won't generate. You get weird file size errors. And the quality of PDF generation varies a lot by language. I'd much rather have an API that I can just call from any of my code if it JUST WORKS.
Now, their pricing is strange and might be a dealbreaker for me. I'd like to see an option to pay per transaction with no cap without having to negotiate with their sales team.
> there's a huge security/privacy headache there
eh, maybe. Some use cases don't require privacy. In my case, I'm mostly assembling PDFs from various sources with my company's documents. No, I don't want a vendor that is going to post my documents to twitter, but I can sleep at night if I have some kind of assurance that they don't use or sell my data.
By "offline", I mean "offline" w.r.t. their servers. The point is: I have some kind of an environment that I'm already using for handling the data underneath the PDFs I'm trying to produce. That environment has a given amount of attack surface area. If they hand me a program that I can run in my environment and that doesn't communicate outside that environment, I have gained additional functionality. This is additional stuff I can do that I couldn't do before, and I've achieved this without increasing the attack surface area that might lead to that data getting compromised.
If I do it the other way around, i.e. instead of them handing me a program, I am handing them my data, then the attack surface area increases. Because every attack against my pre-existing environment continues to be an attack that will compromise my data. But also: Some attacks against their environment would now also end up compromising my data. So it's worse for security.
If I have a car in a garage, and I give the key to the garage to 3 people, it's going to be more secure than if I give the key to 4 people. Because there's one less person who might lose the key and enable a robber to get in.
I don't understand the logic behind the converse idea at all. The idea seems to be: Azure/AWS/whatever is "the cloud". Therefore my data is already in "the cloud". Random company X is also in "the cloud". So I might as well send my data to company X. -- This sounds to me like the What-The-Hell Effect. Like: I've broken my diet because I ate a hamburger. Now I might as well quit the diet. No: Eating fewer hamburgers tomorrow is still better than eating more.
I also don't understand why things have to be architected that way in order to "just work". Weasyprint just works. Pandoc just works. LaTeX just works. I can put them on a computer with no network connection, and they'll happily do their job for me. They give me a lot of functionality and ask very little trust in return. That's a good thing. Whenever that's an option, that's what I'm going to do.
I am also dealing with some clients that are struggling with processing handwriting in their document, but I guess it will be a little far fetched.
At the moment we don’t include Japanese and Korean, but I’ll take a note around your questions.
Handwriting is definitely a different beast, that’s not supported.
Will definitely keep this in mind until it meet my requirements. Is there a mailing list I can sign up for?
Have you written your own code from scratch?
I've connected with several other customers of PSPDFKit over the years and they almost all have much more reasonable pricing.
Beware!
Their prices may be too high, so you declined to pay. I don’t see that as predatory.
So I asked myself: if this kit existed at the time, would we have used it? I don't think so. For all specified pricing plans, the document limit is way too low for what $COMPANY or its clients do. Judging by the progression of the costs, we'd have gone in-house instead of negotiating an Enterprise plan.
If you don't want to adjust pricing, perhaps you could add a consumption based plan. The plan could have a much larger limit, but the client also pays per API call.
Maybe PSPDFKit is interested in integrating Bionic Reading into their products? Take a look at the website (bionic-reading.com) to see if BR can add value to your users.
Let me know if you are interested and best regards from the Swiss Alps, Renato
Oh, looks like they're the exact same thing: a webpage-to-PDF service.
Then there are a whole bunch of "PDF Converter" options, including "HTML > PDF", which seems to be yet another name for the same thing.
For me, all this has a whiff of SEO spam that I find quite distasteful. Just tell me what the product does. Don't try to list it under a collection of different titles in the hope of catching more search terms, it just makes you sound like a snake-oil salesman.
Of course the downside is as you've pointed out - it can be seen as distasteful and in some cases confusing to our users. We will review this on our side and see if it makes sense to remove some of those tools to reduce confusion.
For my personal needs, I use pdftk from the command line.
We have some work planned in that direction, but nothing close to release at this stage.
Long story short, instead of that we spent a few two-week sprints of two-men team and were able to successfully fulfill our needs using open source software. $Company saved hundreds of thousands per year. We also tried to influence company to donate to OSS, that unfortunately never happened, but that's another story.
So please be aware of vendor lock-in and of possible price increase. Always think of a plan-b.
I don't blame you for going down that route. But it feels to me that open source is devaluing our work. PDF is a big and complex specification, there must be thousands of hours of work in the software you chose and yet you are getting all that value for free. Is there any other industry that does this to itself?
But now apparently you’re supposed to use a web API and depend on an external service. This has all kinds of downsides: it has latency (and potentially tail latency). It has larger security issues. It doesn’t work in many sandboxes. It requires an asynchronous call. Callers have to handle timeouts and retries. (If you left pad a string with a normal library, it either works or it doesn’t. With a web service, it can fail transiently or give wrong answers transiently.). It updates on its own schedule, without notice, and cannot be rolled back. And it can charge an utterly outrageous per-call price, so instead of merely profiling and debugging slowness due to making too many calls, developers also have to worry about inadvertently spending hundreds of thousands of dollars.
Replace “left pad a string” with “generate a PDF” and you get this. Why is this desirable?
I suppose things like this may partially explain the stunning slowness of bank websites.
But this doesn’t mean you should outsource computations to a third party remote system. You can have a local (same physical hardware or same data center) off-thread service (or just thread pool) to do this kind of work with much nicer properties.
I used to work on a browser-based document management system, and I would have used (or at least tried) all of these APIs without hesitation. PDFs are a pain and the mish mash of poor functioning tools that exist provides a constant headache.
1) OCR'ing of a PDF is difficult. The only good service is Google, but requires that you break it into pages as images to be performant. This would have simplified things greatly. Even if the PDF has text inside and is not an image, it can be wrong or not laid out in a linear way, so you have to OCR it. Command line tools do not get you very far. An example: if you OCR or text extract a PDF with multiple columns of text, does it handle the columns well?
2) People want searchable OCR'd PDFs where you can highlight the text, even when it's a bitmap underneath. This requires a technique where you overlay transparent text in the exact position of text in the bitmap. This does not come for free and I've only seen this done on proprietary Windows-only software. This alone would be worth it.
3) Office to PDF is an extremely standard need, especially if you want to display them online. But it's not easy. You have to hack together a headless OpenOffice to have it work at all, but it doesn't do a great job. It's difficult to do well because Office docs are like HTML pages in that it greatly depends on the renderer, not to mention the fonts. Microsoft does not offer a service to do this, unfortunately. If you think anything will do, it really won't: when people see their PDF looks very different than what they saw on Word, they get upset.
4) Table extraction APIs are super important, especially if you are trying to automatically extract data from PDFs (e.g. analyze financial disclosures). There have been whole startups dedicated to this.
5) HTML to PDF is also a pain: you have to set up an instance that is running headless Chromium, which can be quite slow. This has become the defacto standard to quickly create complex PDFs. Having a simple API wrapper around this is just one less thing to manage.
The rest of the APIs, like the merging/splitting/watermarking etc., are pretty standard and you do not need APIs if you already have access to the PDF on a server. But if you were in a browser or on mobile, you might not.
Is it really an extremely standard need or just something that appears in the bs corners of our jobs a few times a year.
OCRspace is OK, too, and easier to use. You can just send the PDF. It is free for PDFs with 3 or less pages.
> 2) People want searchable OCR'd PDFs where you can highlight the text, even when it's a bitmap underneath.
OCRspace can also create searchable PDFs: https://ocr.space/searchablepdf
E.g. instead of trying to OCR a PDF, go back to the source document or database or whatever from which the PDF was generated. (Yes, I know that's not always an option. But it should be the first avenue to explore. We should push back against people who send around PDFs as though they were an all-purpose interchange format for textual or structured data.)
I'm a bit puzzled by (3), though:
> Office to PDF ... it's not easy ... when people see their PDF looks very different than what they saw on Word, they get upset
To get a PDF that looks the same as the Word document, just tell them to use the Print to PDF driver from right there within Word.
To add to that, a lot of PDFs (e.g. financial reports) are generated procedurally with ancient code that would have to be rewritten to generate a different format. The underlying database format is often many layers of abstraction different than the final output.
Feel free to take Impira for a spin (https://www.impira.com) if you need to accurately extract data from PDF documents. Would love feedback from anyone who tries it out. [Disclaimer: I am the CEO/Founder of Impira].
There are at least 6 non-Chromium alternative that I can think of in a moment's notice, and also LGPL wkhtmltopdf.
>Office to PDF.... You have to hack together a headless OpenOffice to have it work at all, but it doesn't do a great job... Microsoft does not offer a service to do this, unfortunately.
Microsoft sorta does offer a service to do this. Sharepoint has a word to pdf action, and with some stitching you can make it into an API. There are also several commercial solution (e.g. Spire.NET) for this and also ways exist to mangle the OpenXML into HTML (of course losing some fidelity into the process).
I had to use different OSS tools to do everything I wanted. I was able to access three from within nodejs without touching the disk:
1) Libreoffice CLI for converting doc/docx to PDF. It handled the formatting remarkably well. WARNING: you must have the fonts on the system doing the generating or it will substitute "similar" fonts! NPM: libreoffice-convert
2) NPM pdfjs-dist from mozila for extracting text and finding page numbers.
3) NPM pdf-lib for manipulating PDFs: deleting pages, adding pages from other PDF files (even to the middle of a PDF.)
4) PDF Jam commandline for resizing a pdf `pdfjam --keepinfo --outfile "${path}.resized.pdf" --paper letterpaper "${path}"`;
1) OpenXML is an open standard and like HTML it is interpreted and rendered, much like a browser. MS Word is obviously the reference here. But in certain cases, you will see differences when using other renderers. If you wrote the document in Word and then view it in LibreOffice or wherever, those differences are going to seem pretty glaring. It's possible to fix your document to not run into these issues, but because OpenXML has cascading styles and Word can often times produce quite messy output, it's hard to know what is going to not work well. It has taken the web 20+ years to get to a place where the difference between renderers is small enough to not be a big headache.
2) In OpenXML there is no concept of a page. Everything is relative and only at render time do you know how it looks. PDFs do have a concept of a page and are absolute - so that translation can be quite important and another source of rendering issues. An example of this is in Excel: people do need to print spreadsheets and if you want it to not look obnoxious you have to fiddle with the settings to get everything looking good. If you convert a spreadsheet to PDF you're more or less doing the same thing. However, in an automated context you can't make the judgements needed to make it look good - so you will often times end up with PDFs that have hundreds and hundreds of pages and look awful.
For 1) Microsoft could just release an API or some kind of package that gives you the output that matches Word and it would solve all of this. But at that point OpenXML ceases to be really open because nobody would want to use anything else. For 2) That's a lot harder to solve.