12 ms·

Show HN: PDF API – Generate, convert, and modify PDF documents

• vmchale 5y ago
  dawg why can't you just make a normal program I don't want a REST API
  • fullyforged 5y ago
    What languages do you need support for?
    • nonameiguess 5y ago
      How about none? Any service that can be passed text from an http request can be passed text via argv and called from the command line. The fact that a helper program runs on the same host rather than across a network doesn't mean you can only use it via direct function call. Imagine if the developers of pandoc didn't actually distribute pandoc and only allowed you to invoke a pandoc instance running on their servers remotely.
• koinexpert 5y ago
  Very cool! Consider 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.
  • lgvld 5y ago
    Cool idea, yep. ;-)
• martin_a 5y ago
  Which rendering engine are you using in the backend?
  • whylo 5y ago
    The metadata on an output PDF I tested says Skia (though I guess that could be being wrapped by another library)
    • edumucelli 5y ago
      Maybe this Skia: https://github.com/google/skia https://github.com/google/skia
  • fullyforged 5y ago
    We're based on PDFium, but there's a lot more going on than just that - see https://pspdfkit.com/blog/2019/contributing-to-pdfium/ https://pspdfkit.com/blog/2019/contributing-to-pdfium/ for an overview.
    • martin_a 5y ago
      So, no compliance with printing industry standards. That's a pity.
      • muhehe 5y ago
        I don't know about printing industry and their compatibility requirements. Would you mind elaborate a bit on this (I occasionally do some pdf output, so I'd like to avoid basic mistakes)?
        • martin_a 5y ago
          What you would typically be looking at, is compliance witt the PDF/X standards [1] in various levels, which are basically ISO norms for PDFs. 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 https://en.wikipedia.org/wiki/PDF/X
• lgvld 5y ago
  Very useful product, congratulations. ;-) 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!
  • fullyforged 5y ago
    Thanks! This is Claudio, PSPDFKit's CTO. 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.
    • magicalhippo 5y ago
      > At this point in time the price is per generated document - irrespectively of how complicated the operation is. 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.
      • fullyforged 5y ago
        The volume you’re describing is totally doable. We can do custom plans if you’re interested - there’s a contact link at https://pspdfkit.com/api/pricing/ https://pspdfkit.com/api/pricing/.
• kareemm 5y ago
  Is this used for creating pdfs from scratch (a docraptor alternative)? Or filling out pdfs programmatically (a docspring alternative)?
  • fullyforged 5y ago
    You can create a PDF from scratch starting from HTML - see https://pspdfkit.com/api/documentation/developer-guides/pdf-generation/ https://pspdfkit.com/api/documentation/developer-guides/pdf-.... Note that HTML generation has a few nice quality of life additions around headers/footers, logos and conversion of HTML forms to PDF forms, which are things that you don't normally get with the print to PDF workflow you would normally build from scratch. 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.
• steerablesafe 5y ago
  From the pricing page, limits seem to be on number of documents, not number of pages. Is the number of pages per document also limited?
  • fullyforged 5y ago
    No, just number of created documents.
• m12k 5y ago
  I recently discovered that search-replacing text in a PDF without changing the layout is much harder than I thought it would be (a customer forgot to change their billing address, and now that the invoice is finalized, Stripe won't let me edit anything, so down the PDF-editing rabbithole I went). I would love it if I could just use an API for this.
  • martin_a 5y ago
    You only need an Acrobat Pro for that.* That's daily business for me, although not with invoices but printing data. * (becomes harder when the font is not embedded/existent as a subset, but Acrobat let's you choose another font, so no big deal.)
    • NetBeck 5y ago
      LibreOffice Draw edits PDFs pretty well.
  • laurent123456 5y ago
    If it's just one off, I'd draw a white rectangle over the text that needs to be changed, then add the text on top of that.
  • danielrhodes 5y ago
    This isn't easy because PDFs are PostScript, so text is laid out absolutely. You can make very small changes but a larger change requiring a reflow of the text would break things. In some cases it is possible to convert the PDF to a Word document, make edits, and then save it back to a PDF.
  • citruscomputing 5y ago
    What I used for this exact problem was pdftk's `stamp` option, with a stamp pdf that was just a white rectangle with text on it, as a sibling commenter mentioned. Worked for several hundred documents!
  • zubspace 5y ago
    There are so many ways to layout text on a PDF page, that this is nearly impossible to implement for all scenarios. I don't know a PDF editor which works in all cases. 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.
• wfn 5y ago
  Very nice and useful product! 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/ https://www.zealid.com/en/
  • arkgil 5y ago
    Signing is something we'd like to explore, we often hear from folks who'd want to simplify their signing workflows. Thanks for the feedback!
• gyulai 5y ago
  Not a good usecase for an online API. To the extent that those PDFs could include sensitive information, there's a huge security/privacy headache there, with no real benefit when compared to performing these functions offline. It also seems to me a lot more expensive than alternative ways of doing the same thing.
  • simion314 5y ago
    Would work if you want to publish the pdf anyway.
  • arkgil 5y ago
    That's a great point. For folks that have strong privacy needs, we do have an on-premise product that provides the same functionality [1]. [1] https://pspdfkit.com/server/processor/ https://pspdfkit.com/server/processor/
    • gyulai 5y ago
      So what exactly does that leave? A wrapper that you've created around weasyprint, pandoc, latex, ghostscript, imagemagick, and stuff like that? 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.
• stevenminhhh 5y ago
  Do you have any plan in your roadmap to support different languages in the OCR feature? I'm specifically interested in recognize and processing PDF files written in Japanese and Korean. 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.
  • fullyforged 5y ago
    This is the list of supported languages: https://pspdfkit.com/api/pdf-ocr-api/#supported_languages https://pspdfkit.com/api/pdf-ocr-api/#supported_languages 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.
    • stevenminhhh 5y ago
      Thanks. I have been dealing with ton of headache from my projects since modifying PDFs can be very problematic. Rather than stitching up multiple libraries, I would rather suggest one platform to handle everything. Will definitely keep this in mind until it meet my requirements. Is there a mailing list I can sign up for?
• somehowadev 5y ago
  The pricing may need to have a revisit! Enterprises would probably be the most keen and also find better alternatives for the cost.
• etothepii 5y ago
  How have you avoided the AGPL headache that comes with almost all the open source libraries for PDF editing? Have you written your own code from scratch?
  • arkgil 5y ago
    Our engine is based on Google's PDFium, which is Apache licensed. We use it for rendering and reading the PDF object tree. Editing, annotations, etc. are all built on top of that.
• ianhawes 5y ago
  Just an FYI but PSPDFKit has a very predatory sales model. Our organization received pricing that was generally very high and we pushed back on it because we were a startup and it was outside of our budget. I've connected with several other customers of PSPDFKit over the years and they almost all have much more reasonable pricing. Beware!
  • user_7832 5y ago
    I've always wondered (as someone who hasn't made corporate purchases), wouldn't there be a point where it would be easier to teach all employees LibreOffice (Draw) instead of buying proprietary/expensive software that might break/has external dependencies?
  • ethotool 5y ago
    I experienced the same. We ended up developing our own solution and no longer have to rely on any 3rd party framework.
    • ianhawes 5y ago
      We did the same.
  • upbeat_general 5y ago
    Maybe I’m missing something but how is that a “predatory sales model”? Their prices may be too high, so you declined to pay. I don’t see that as predatory.
    • ethotool 5y ago
      They claim to charge based upon your requirements, your business model and revenue. If you are a startup they will most certainly overcharge you for their framework. They also want access to your financials to make sure you would be in compliance with the contract.
  • deleted 5y ago
    [deleted]
• yyyk 5y ago
  A few years ago, $COMPANY had similar needs for a client. I ended up creating an in-house solution, which has a surprisingly close API (well, there are only so many ways to do this). 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.
  • arkgil 5y ago
    Thanks for the feedback! For those that need larger volume, we also have an on-premise product: https://pspdfkit.com/api/documentation/deployment-options/ https://pspdfkit.com/api/documentation/deployment-options/.
• renato_casutt 5y ago
  Hi Arek...congrats on the launch. 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
• jfk13 5y ago
  Taking a quick look at https://pspdfkit.com/api/documentation/tools-and-api/ https://pspdfkit.com/api/documentation/tools-and-api/, I'm puzzled.... what distinguishes a "PDF Generator" from a "PDF Creator" from a "PDF Writer"? How would I know which one I want? 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.
  • deleted 5y ago
    [deleted]
    • deleted 5y ago
      [deleted]
  • arkgil 5y ago
    I'm sorry you find it distasteful - that was never our intention. What we found was that a user searching for a PDF generator, creator or writer are generally looking for the same solution - to create a PDF. So by repositioning our tool we were hoping to provide a better landing page experience for users that were searching for one of those specific keywords. 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.
• mdellavo 5y ago
  How well does this handle large tables that span pages? That seems to be a key differentiator for most PDF libs I sampled. I'd assume this works well if it's coming from Chromium
  • arkgil 5y ago
    Do you mean tables when converting HTML to PDF, or simply rendering the PDFs with tables in them?
    • mdellavo 5y ago
      simply rendering tables - most of the (python) pdf generation libraries I evaluated a few years ago all had the same limitations (reflow is hard) around laying out large multipage tables. We went with a headless chrome service to print to pdf which did not have the limitation.
      • arkgil 5y ago
        We've had customers in beta trying it out with multi-page tables and we've heard positive feedback.
  • fullyforged 5y ago
    If you have a sample HTML you wanna try, you can use https://pspdfkit.com/pdf-sdk/web/pdf-generation/ https://pspdfkit.com/pdf-sdk/web/pdf-generation/ and paste HTML there - the generation engine is virtually the same.
• brudgers 5y ago
  It looks interesting, but addresses a scale that I don't work on. For my personal needs, I use pdftk from the command line.
• SilentM68 5y ago
  Does this API allow for the generation of accessible documents, such as PDFs, which can then be read by blind persons using a screen reader such as Jaws or NVDA? These tools have the ability to bring up a dialog box (e.g. elements list) listing the links, headings, form fields, buttons and landmarks present on documents, (e.g. html, pdf, and so on) that blind people would need in order for them to navigate a document.
  • fullyforged 5y ago
    We’ve done some tests in that area and while Chromium is technically able to generate tagged PDFs, which would be accessible for the most part, it’s far from perfect. We have some work planned in that direction, but nothing close to release at this stage.
• zihotki 5y ago
  Some time ago at a $Company we needed to generate pdfs and also OCR incoming documents. In order to quickly release a product we decided to use online API from a $Vendor. Initial price was quite OK-ish but a year-two later we saw a significant increase in price. At that time we also started moving to on-premise hosting to decrease latency and to address other GDPR stuff. Considering high volume of documents it was just too much for us and the $Vendor didn't want to negotiate. In addition to that we also needed to implement reports to show to the $Vendor how many items we procesed for on-premise licensing.. 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.
  • tonyedgecombe 5y ago
    >We also tried to influence company to donate to OSS, that unfortunately never happened, but that's another story. 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?
• amluto 5y ago
  I find this utterly bizarre. Once upon a time, if you wanted to left pad a string, you would just do it. A while later, people discovered that you could use a library. (I’m joking a bit here, but libraries are genuinely useful.). With a library, you get to pick from various schemes and schedules for updating the library, but you have a degree of control. 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.
  • ho_schi 5y ago
    Same on my mind. Let say you have to create an invoice for a customer and your operations stop just because your not using {Cario, Skia, PoDoFo, JagdPDF, Haru, Whatever} on the local environment but relied upon an external service which halted. This introduces a huge dependency chain across the web. But they don't provide anything which cannot provided autonomously by a local library. Integrate with external services because you must and not because you can.
  • deleted 5y ago
    [deleted]
  • newlisp 5y ago
    Nodejs forces this architecture(no, worker threads are not a solution, they are heavy and have too many restrictions), you don't want to slow down the event loop with heavy PDF processing.
    • 5y ago
• roschdal 5y ago
  OpenPDF https://github.com/LibrePDF/OpenPDF https://github.com/LibrePDF/OpenPDF
• smashah 5y ago
  I was contracted to make a legal document generation service for a client. I looked at all of these tools and decided to just use HTML/CSS and then print to PDF via puppeteer on a serverless cloud function.
• voiper1 5y ago
  I recently went down the PDF rabbit hole for a project. 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}"`;
  • danielrhodes 5y ago
    Libreoffice only does a mediocre job of rendering Word documents. There are a number of cases where it really mangles things. An example would be some types of bulleted lists or indentation.
    • wolverine876 5y ago
      Given the GP's and your differing experiences, I wonder in which circumstances it works and in which it doesn't.
      • danielrhodes 5y ago
        In most cases it is adequate. But there are a couple factors to consider: 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.
• yashg 5y ago
  Congratulations. Last year I launched a PDF generator API here on HN, got zero upvotes, you have managed to get to front page. Wish you all the success.
• gw67 5y ago
  Would be great to have a file upload button to test the OCR API from the UI, without to perform the CURL. Just to test how your API works from UI.
  • fullyforged 5y ago
    You can try it at https://pspdfkit.com/pdf-sdk/web/ocr/ https://pspdfkit.com/pdf-sdk/web/ocr/, the OCR functionality is shared with our SDKs.
• throw03172019 5y ago
  It all sounds great until you get a quote. $15,000/yr for an API to sign a PDF. Come on.
• sideproject 5y ago
  Nice set of tools!! I recently launched a PDF-related project. https://www.scholars.io https://www.scholars.io It's a tool for reading research papers (PDFs) together with your colleagues. You can read, annotate, comment etc. Needless to say, it led me down quite deep into the PDF world and it.. was interesting.
  • wolverine876 5y ago
    Incidentally, I wonder if you can answer a question: I want my books in an electronic format, that will be usable for the rest of my life or longer, and which preservers annotations. As far as I know, PDF/A is the only format that fits the first two specs. I know annotations are in the PDF specs but is it reasonable to think that annotations I make today will be readable - and updatable - in (e.g.,) 30 years?
    • gettalong 5y ago
      Yes, that is quite reasonable. The simple text annotations are quite easy to work with when using a PDF library and the standard tries to be backwards compatible where sensible. The PDF 2.0 standard removed some parts of PDF 1.7, like the proprietary XFA forms. But most things stayed in PDF 2.0 and one can expect that those annotations will also be available in future iterations of the PDF specification. And generally, since future PDF viewers will need to be able to view older documents (think: all the (signed) documents created by governments), you can expect PDFs created today to be usable in 30 years and more.
      • wolverine876 5y ago
        Thank you.
• passenger09 5y ago
  Really handy service, even if there are probably a lot out there already. The following might be worth to check out: - https://docspring.com/ https://docspring.com/ - https://bulk-pdf.com/ https://bulk-pdf.com/ However a good documentation you have there!
• TheRealNGenius 5y ago
• kvz 5y ago
  > What differentiates our API from others is that you can chain together multiple “actions” as part of a single API request. https://transloadit.com https://transloadit.com offers similar composable workflows in a single request, and supports more file types besides PDFs. Disclosure, I am a founder :)
• BOOSTERHIDROGEN 5y ago
  I’m sorry if this stupid question. What kind of industry (having thousand process document a month) or use case for someone using this maybe an expensive tools ? If there’s a use case what is the manual process that usually happen, thanks
• jwillmer 5y ago
  We need to offline convert HTML to PDF. We created a small docker container with Chromium and Selenium and added a small HTTP API layer on top. Works like a charm and it is easy to keep it up to date.