When you write a PDF library, there are design trade-offs all the way down, depending on use cases. (Just “in-memory” is already an important design trade-off, because the PDF format is intentionally designed to not require the whole PDF to be loaded into memory at once.) It would also be antithetical to preferring deep modules with minimal interfaces over shallow modules with broad interfaces [0]. Lastly, in managed environments like the JVM, a C-interface library would come with additional complications and overheads.

[0] https://dev.to/gosukiwi/software-design-deep-modules-2on9

> The ecosystem would be greatly improved if someone made a great (probably rust based) in-memory low level pdf reading and writing data structure.

> Not sure what would economically cause this to happen, but it would be great.

Writing a library that is better than all the others is difficult to begin with. Continuing to upgrade and maintain it and fix bugs is even more difficult. Even with the right funding, you'd have to find someone who wants to keep at it year after year. When they inevitably lose interest, you'd have to find somebody else to take the reins--and weather the storm of complaints during the down time.

In short, thank you for volunteering to write and maintain this library for the rest of your life! :)

  The ecosystem would be greatly improved if someone made a great (probably rust based) in-memory low level pdf reading and writing data structure.

Actually debugging a PDF parsing issue as we speak and actually started writing a parser (partially to understand the issue, partially as a last resort as the code in the parser I was debugging felt a bit shoddy).

The PDF format is frankly quite horrible, extended over the years by kludges that feels more or less like premature optimizations in some cases and bloated overkill in others.

While theoretically a nice idea, the issue is that there is just so many damn object types with specialized properties inside a PDF that you'd basically end up with all complications of a FFI for each binding you'd do to expose a sane subset.

Theoretically one could perhaps make a canonical PDF<->JSON or similar mapping from an established library that most PDF data consumers/generators could use if memory usage isn't too constrained (because the underlying object model isn't entirely dissimilar).

I don't think this _really_ contributes to the conversation, but I think we can sum this entire post up with just one XKCD comic.

https://xkcd.com/927/

> someone made a great ... in-memory low level pdf reading and writing data structure

Are you suggesting Adobe's Core Object Application Programming Interface (COAPI) for PDF isn't sufficient?

Kidding!

I worked on print production software in the '90s. Stuff like image positioning (eg bookwork), trapping, color separations, etc. Adobe's SDKs, for both PostScript and PDF, were most turrible. For our greenfield product for packaging (printing boxes), I wrote a minimalist PDF library, supporting just the feature set we needed. So simple.

Of course, PDF is now an ever growing katamari style All The Things amalgamation of, oops, sorry I ran out of adjectives.

Back to your point: after URLs and HTTP, the DOM is the 3rd best thing spawned by "the web".

The DOM concept itself. Isomorphism between in-memory and serialized. That its all just an object graph. Composition over inheritance.

Not the actual DOM API; gods no.

I understand that API design is wicked hard. But how is it that of the Java tools, only JDOM2 (the sequel) managed to get the class hierarchy correct? So that incorrect usage is not permitted?

(I haven't looked at popular libraries for other languages. I assume they all also fell into the trap of transliterating JavaScript's DOM's API. Like dom4j and successors did.)

I'm just repeating your point (I think) that Adobe should have staked a strong starting conceptual position on PDF internals, what a PDF is. Something more WinForms and less Win32.

30+ (?!) years later, I'm still flubbergasted by PDF's success, despite Adobe's stewardship.

PS- And another thing...

For a print description language, I greatly preferred HP's PCL-5. Emotionally, it just feels more honest somehow. Initially, Adobe couldn't decide if PDF was for print control or documents. Customers wanted documents, so Adobe grudgingly complied, haphazardly.

At least "the web" had/has committees.

I just used these tools to parse a few hundred thousand PDF paystubs to get data into our new financial system. 10/10 would use again.

I use these all the time. They are great.

Came here to say this. Qpdf is my go-to for manipulating pdf files on the command line. Encrypting, decrypting, extracting and merging pages.

It's Apache-licensed and written in C++.

I found PDF SAM basic ("split and merge") well done: https://pdfsam.org/en/pdfsam-basic/. That one is open-source and multi-platform, they have more features in a paying superset project.

If self hosting is an option, I've found Signature PDF to be quite good.

https://github.com/24eme/signaturepdf?tab=readme-ov-file#sig...

How about this: https://tools.pdf24.org/en

It allows installation for offline use too.

i've tried 'pdfcpu images list' on a random pdf i've had lying around and the tool unexpectedly started downloading some font from unspecified internet location to my local disk.

sorry, too spooky even for october. :-)

I had to bash my head against the wall and submit myself to paying for a creative cloud license. At least acrobat just works. Although I wish there was a reasonable alternative.

There's also Master PDF, and it's also available for Linux: https://code-industry.net/masterpdfeditor/

> It’s free and available for everything except Linux.

I was unable to find the link for OpenVMS, Apple II, and DEC Alpha binaries, could you show me where to find it?

As nice as it looks, I have a lot of trouble believing the "we have magic money, it's free because that's good for business" logic.

    PDFgear is free of charge, and we don’t generate income through any hidden means. We Do NOT misuse or sell user data and we Do Not display ads. Here’s how we keep operations running: 
    We’ve secured investment to cover operational costs, including team expenses and technology like the ChatGPT API. We’re also experienced in optimizing technology usage to manage costs more effectively.

I found it suspicious, they formerly sent stuff too their cloud without it being obvious, and the company seems to mod their own subreddit.

I use https://github.com/Krasjet/pdf.tocgen.

It's not quite fully automatic, but it certainly saves a lot of time over doing it completely by hand.

Why wouldn’t a company sign documents they create automatically? This is about a cryptographic signature that lets the user verify authorship, not a visual signature in the PDF, right? So it would still be useful to be able to verify that a bank statement is really from my bank, even if it was generated without human interaction.

CEOs often need to sign changes to employment terms or options/vesting terms and have hundreds if not thousands of employees. They don't have the time to go through and sign all of those contracts.

Its no different than the analog ages where a secretary would go through and stamp all the contracts with the CEOs signature.

My bank can issue a signed certificate for any of you account movements if you need to provide proof of them. They come signed both digitally and handwritten by the branch's director. But you wouldn't expect the director to be there sitting and signing all certificate requests that arrive, right?

Imagine you need to sign 25 pdf documents. You read them on the screen and then batch-sign them (instead of signing them with the vewing software). This is just an example.

> Every time someone reinvents the wheel, it becomes a little rounder.

Not sure if this particular library is an improvement, but even if it serves nothing but the author’s enjoyment, or education, it’s a win.

It makes sense to me. They made a PDF library for Python first. Having a PDF library for your preferred language is a good thing.

And it’s natural to then build a cli tool on top of the library they already made.

It’s not open-source, so practically the question is equivalent to “why reinvent the wheel by creating libreoffice when there’s a perfectly good Microsoft office suite out there”

This was my first thought, but after reading the comments here, I see I had no idea how many other alternatives already existed, so why not add another one.

Actually pdftex or luatex, but you are completely right, it can load a pdf file and do a lot of things with it.

Yeah, I've been expecting someone to work up a system where:

- source file is .md

- file is compiled to .pdf _and_ the .md source file is included as an attachment

- when working with the file beyond viewing as a .pdf the .md is extracted and used instead of the .pdf

The LaTeX folks have a similar system ages ago where the .tex source would be included in a .pdf made from a .tex file for embedding in documents so that it could be sent in say an e-mail and then edited by the recipient --- absolutely awesome for discussing math via e-mail.

Swiss Army knives seem to be as popular as ever. What do you mean, doesn't have a positive connotation?

They're great hiking, camping, traveling, in backpacks and bags.

What's wrong with it as a knife? It's perfectly sharp. Obviously it's not a full-sized chef's knife, but it will cut your apple or twine or packing tape. It's a multitool. It does lots of things. A tool of "last resort" seems to miss the point -- it's not meant to use at home, when you have a full-size screwdriver and bottle opener and corkscrew. It's for traveling with you. And it's great at that.

SAK's are iconic. I don't think your take is a common one.

And thus the Leatherman(tm) was born from its ashes.

And too quickly smothered in copycats for its name to become the new metaphor.

9/11 killed them. They used to be sold in airports.