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

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.

This is the list of 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.

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

Thanks!

> Most PDF generators out there are not able ...

Do you know of any compatible?

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.