Why are open-source PDF APIs so hard to come by?

Question

PDFs are inescapable, what surprises me is the lack of open-source tools available for interacting with them via some sort of API. One example which sticks in my mind was when I was using .NET to parse some PDFs and my program threw a TrialLimitMet error because I hadn't purchased a key to use in the Nuget package I was using. I've since struggled to find well maintained and extensive packages for NodeJS and Python.

I noticed that the PDF specification, from ISO, costs a non-trivial amount of money for someone just interested, which leds me to believe it might be restricting the number of open-source developers.

Before researching, it was my belief that Adobe owned the PDF filetype, I know see that that may not be entirely true but they may

Is there a reason that this sort of, IMO unhealthy, ecosystem exists?

Answer 1

PDFs are really complicated, but also have significant value – precisely because they are so ubiquitous. PDFs are the format for exchanging documents that shouldn't be edited (like invoices), the format for distributing layouted content like print-ready files, and with PDF/A the format for long-term electronic archiving.

While Adobe has tons of extensions and special features in some PDF variants, those are rarely used. The worst PDFs I had to deal with used embedded macros to dynamically generated additional pages and QR codes based on form input, or embedded multimedia into the page. That is not normal. Many people don't even use Adobe software for viewing PDFs, so anything more fancy than basic forms is not going to work reliably.

There is an open source ecosystem for dealing with PDFs. Tools like PdfTeX and Cairo can be used for PDF creation, Poppler for PDF parsing and rendering, Ghostscript for rasterization, iText for creation and manipulation. I'm not sure if LibreOffice has a custom PDF backend.

But, many of these use copyleft licensing (AGPL or GPL). Some of these use a dual-licensing scheme, where users can pay for a proprietary license if they don't want copyleft licensing terms. And commercial users do pay, because a good PDF API is so valuable.

The incentives of all involved actors are (mis-)aligned such that a permissively licensed Open Source PDF library ecosystem is unlikely to spring up:

• PDF is a complex format, so that there's a high barrier to entry in this “market”. Development costs for a “good enough” PDF library are high. The cost of the specifications is only a small aspect, compared to the time investment.
• Commercially motivated Open Source authors will have to run the numbers: is it cheaper to pay for development of a new PDF library, or is it cheaper to pay for a proprietary license for an existing library? Hint: PDF API vendors like iText know this and can price accordingly. This problem could be avoided by a large consortium (effectively crowd-funding creation of a new API), but so far no one has organized this.
• Philosophically motivated Open Source authors are probably entirely happy with copyleft-licensed libraries. While there is also a community of people that strongly prefer permissive Open Source licenses over copyleft licenses (greetings to the OpenBSD crowd), PDF manipulation is neither an integral part of computing nor that terribly exciting to motivate some individuals to start and complete this kind of project.

Answer 2

A few years back I had as a task to find a simple way to customize customer on demand reports.

Using Perl, I coded a general parser that recognized standard tags in all of the reports and allowed for positioning, whereby files with the report ID, the customer and department allowed for search and replace within the report. The ability to either have a text or image banner, or a company logo was added. there were also a bunch of other features that I begin to forget.

Long story short, Perl had over 150 routines for PDF production that were in general fully functional, documented and free available from CPAN. In the end everything I was looking to do could be achieved rather quickly with what was available for Perl.