There are a million python libraries and tools to do some overlapping subset of the things you'd want to do with a pdf.
There are no doubt another million in other languages.
These are each basically bundles of some of the transformations you'd want to make to the same underlying data structure.
So, complex pdf scripts often need two or three different libraries to get their thing done, which is wasteful at borh a dev effort and computational level.
The ecosystem would be greatly improved if someone made a great (probably rust based) in-memory low level pdf reading and writing data structure.
PDF libraries in any language could switch to using that structure and library internally, with the carrot that the switch would result in needing less code, and likely being some combination of faster and safer.
And then if they just exposed get_structure_pointer() and set_structure_pointer(), they could all interoperate for free. (Another carrot for joining -- small libraries could usefully add features and be adopted without needing to pick an existing popular library to glom onto.)
Not sure what would economically cause this to happen, but it would be great.
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.
> 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! :)
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).
> 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.
"Adobe couldn't decide if PDF was for print control or documents"
Apparently people don't understand the history of PDF. PDF was originally a way to encapsulate PostScript so you could display it on a screen. Unlike PCL, Postscript (and PDF) were device-independent, with a WYSIWYG guarantee. Postscript and PDF are literally the history of WYSIWYG on personal computers and computer-based printing/typesetting.
PDF is not "print control" in the sense of a job control language. PDF has always been about documents, and the features of PDF files can be seen as an attempt by Adobe to both drive and follow the market's evolution of document handling.
PDF is complicated because it's used widely for lots of different things, including printing. And if you've never worked in the printing industry you have no idea how much of a PITA it is.
PDF succeeded for a lot of reasons, but probably the easiest explanation is that they were easier to create - you just printed it and the PDF printer driver spat out a PDF file that you could share everywhere.
One of my first jobs was at an isp/web/cohost company. We had a big bank of modems for dialup customers, had some customers who terminated isdn with us, a rack of colocation and built websites as well.
The company was partially owned and housed primarily in a print shop, we worked above the press floor and I was sometimes pressed into service helping when we were slow (I had some experience working in a print shop in highschool (helping with pagemaker and helping to run the big hidleberg), similarly in college.
Nothing like ending your day writing perl cgi scripts and troubleshooting customers damn winsock configurations and then going home and coughing up whatever color was running on the presses that day.
curiously poppler doesn't mention that anywhere on their website, but the library comes with a similar suite of tools, typically available in linux distributions.
How do you use qpdf for extraction when its README states “qpdf does not render PDFs or perform text extraction, and it does not contain higher-level interfaces for working with page contents.”
Not the person you're replying to, but when they said "extraction" I believe they're talking about extracting pages from a PDF (like "splitting" the PDF apart, page-wise), not text. At least that's a thing I've used qpdf for in the past.
Which is also what the "extract" button does in Adobe Acrobat Pro DC for Professional Enterprise Customers or whatever they're calling it now, so it's arguably a term of art for PDFs.
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.
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.
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.
Not the same thing but just want to shoutout https://www.pdfgear.com/ as one of the only viable alternatives to adobe for intermediate level PDF tinkering. It’s free and available for everything except Linux.
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.
In the future, most features will remain free, but there will be a fee for some advanced options. Paid options may include AI-driven tools requiring cloud computing and special PDF conversion features. This balanced approach will allow PDFgear to remain widely accessible while meeting users’ evolving needs with advanced solutions.
One feature I would love is the ability to automatically generate the table of contents / “outline” metadata for a pdf. I run across a lot of old book pdfs without that metadata, which makes navigation annoying. Kybook3 has a version of this that doesn’t quite work. Maybe in the age of LLMs, this is now feasible.
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.
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”
In case anyone gets confused, PDFTk Server is just the name for the CLI tool, which hasn't been updated in 10y+ (and annoying to compile due to newer GCC versions removing GCJ). The pdftk provided in various distros (incl. Debian, Fedora, Arch, NixOS) is pdftk-java, a 3rd-party pure Java port of the original tool.
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.
This, is gorgeous! I absolutely hate the PDF ecosystem, and how painful it is to get a reasonably simple tool to just do basic edits to files (adding/removing pages, combining multiple PDFs etc). I particularly hate how hard it is to find good swiss army knives for it, and how you always land on sketchy websites to do simple things to a file.
This looks dead simple to use! LOVE IT.
The one feature request I have is for adjusting margins (adding/removing fixed amount of space from every page, optionally adding/removing different amounts from odd numbered pages). Target audience: People who want to read PDFs on small ebook readers.
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.
That's a good concept but I don't think Markdown is expressive enough for all the layouts & formatting that people typically want in PDFs. More likely that the source format would be something like HTML or SVG or .docx.
Restructured text has mostly 1:1 correspondence with Docbook. I use an XSLT transform to convert its XML schema into Docbook and PDF from there via XSL-FO.
This is totally an aside, but I wonder how long the "Swiss army knife" metaphor will hang on in popular culture. People generally use it to indicate that something does a variety of things, but I'd say many of younger generation have never touched if even seen such a knife in their life, and even among older generations it doesn't have a positive connotation.
Like when I hear something is the Swiss army knife of something, my take is that it does a lot of things poorly and there are better specific tools for every need. Like if you need a really terrible knife or bottle opener or screwdriver or saw, a Swiss Army knife has you covered. But it should be a tool of last resort when you have no other options.
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.
Obviously it's not the only game in town ever since Leatherman made the pliers-style tool popular as well.
But you can just look up the various brands on Amazon to see that SAK's continue to sell very well, by "x bought in the last month."
It's nowhere near 1%, I don't know where you're getting that.
Edit: according to [1] Victorinox has the #1 spot in market share in multitools. The share is a bit higher than it is for SOG and Leatherman, though they're both close.
Lots of cheap (and good) Chinese alternatives entered the market recently but I'd say Victorinox is still going strong. In Poland it's sold everywhere and the brand is very recognizable.
It isn't as popular as ever, at least not in the Western world. I don't know what your frame of reference is, but it is positively non-existent compared to a couple of decades ago. Approximately zero kids, give or take a few, put one on their Christmas list, where when I was a kid it was many kid's dream item. I would say the most common buyer today are middle-aged men who buy it just as a thing to own because they remember how desirable they were when they were in Scouts in their teens.
>A tool of "last resort" seems to miss the point
It is quite literally a tool of last resort, and in practice people who actually own one (such as myself) have often never, ever actually used any of the options available on it because they're terrible options and we always have something better available.
Like a legitimate folding camping knife, which we all have in our camping supplies. An infinitely better knife. A tiny multi-screwdriver kit. The Leatherman brand went big by making a legitimately good, well constructed pair of pliers that they add some "in a pinch" options.
Serious campers who portage and go deep country have a proper assortment of gear and never lean on their SAK. The rest of us usually get there in a car and have a...proper assortment of gear.
But again, if you're in a situation where you have to use one of the tools on a SAK, you probably screwed up and it's a serious compromise. It just isn't a compelling metaphor for software tooling.
>Victorinox is literally the #1 multitool brand by market share
This doesn't repudiate anything I said, and it's a particularly weird canard.
>That's why it's a popular one
Increasingly the only ones I see leveraging the metaphor are English as a second language writers (note that the idiom originates in English and is a calque in other languages) who perhaps came across it somewhere. I would hardly call it "popular", and I pointed out the reality that many readers, such as myself, find it a negative description, similar to someone calling themselves a "jack of all trades". Your defensiveness of SAK does not change this, and your attempts at invalidating my statement borders on bizarre.
> are English as a second language writers who perhaps came across it somewhere
Your prejudice is showing. Where would you even get an idea like that?
I hope you understand that people whose first language isn't English also use SAKs. It's not just an English thing. They're not trying to repeat some unknown object they've only encountered in metaphor. The tools are literally Swiss. And popular around the entire world.
You’re absolutely right. I was just in Switzerland and I’ll tell you the Victorinox shops have endless visitors from all kinds of tourists. Swiss Army knife metaphor is timeless, at least for those who go out. Maybe there’s a generation where outdoor activities is an unknown because computers. At this point the other person is just being argumentative.
Arguing that my observations are invalid because you were in a Victorinox shop in Switzerland is the chef's kiss on this ridiculous discussion.
In the future, just move along. The other argumentative guy had no reason to get defensive about SAK, and this whole worthless discussion, from a basic observation about idioms and ill-suited tools, is a waste of bits.
It doesn't remotely repudiate anything I said, more than saying that Gpvos is the #1 seller of buggy whips ergo ipso facto buggy whips are super popular. This is not a hard logical chain to follow, so good god.
But secondly, even that site claimed they have what, a 20% marketshare of multitools from once owning the market entirely to themselves? Even if we were so profoundly simple that we believed that being the biggest vendor in a market validates the market, this particular example is hilarious.
Opinion from 10 years ago, I suspect still valid:
There are a million python libraries and tools to do some overlapping subset of the things you'd want to do with a pdf.
There are no doubt another million in other languages.
These are each basically bundles of some of the transformations you'd want to make to the same underlying data structure.
So, complex pdf scripts often need two or three different libraries to get their thing done, which is wasteful at borh a dev effort and computational level.
The ecosystem would be greatly improved if someone made a great (probably rust based) in-memory low level pdf reading and writing data structure.
PDF libraries in any language could switch to using that structure and library internally, with the carrot that the switch would result in needing less code, and likely being some combination of faster and safer.
And then if they just exposed get_structure_pointer() and set_structure_pointer(), they could all interoperate for free. (Another carrot for joining -- small libraries could usefully add features and be adopted without needing to pick an existing popular library to glom onto.)
Not sure what would economically cause this to happen, but it would be great.
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! :)
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).
You can do:
(Modify out.json as liked) (Disclaimer, I wrote it.)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.
"Adobe couldn't decide if PDF was for print control or documents"
Apparently people don't understand the history of PDF. PDF was originally a way to encapsulate PostScript so you could display it on a screen. Unlike PCL, Postscript (and PDF) were device-independent, with a WYSIWYG guarantee. Postscript and PDF are literally the history of WYSIWYG on personal computers and computer-based printing/typesetting.
PDF is not "print control" in the sense of a job control language. PDF has always been about documents, and the features of PDF files can be seen as an attempt by Adobe to both drive and follow the market's evolution of document handling.
PDF is complicated because it's used widely for lots of different things, including printing. And if you've never worked in the printing industry you have no idea how much of a PITA it is.
PDF succeeded for a lot of reasons, but probably the easiest explanation is that they were easier to create - you just printed it and the PDF printer driver spat out a PDF file that you could share everywhere.
One of my first jobs was at an isp/web/cohost company. We had a big bank of modems for dialup customers, had some customers who terminated isdn with us, a rack of colocation and built websites as well.
The company was partially owned and housed primarily in a print shop, we worked above the press floor and I was sometimes pressed into service helping when we were slow (I had some experience working in a print shop in highschool (helping with pagemaker and helping to run the big hidleberg), similarly in college.
Nothing like ending your day writing perl cgi scripts and troubleshooting customers damn winsock configurations and then going home and coughing up whatever color was running on the presses that day.
curiously poppler doesn't mention that anywhere on their website, but the library comes with a similar suite of tools, typically available in linux distributions.
i have found them very helpful.
https://en.wikipedia.org/wiki/Poppler_(software)#poppler-uti...
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.
Same, in conjunction with some of the format conversion tools that come with Ghostscript, and PDFgrep (https://pdfgrep.org/).
For low-level work, qpdf can be quite useful: https://github.com/qpdf/qpdf
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++.
How do you use qpdf for extraction when its README states “qpdf does not render PDFs or perform text extraction, and it does not contain higher-level interfaces for working with page contents.”
Not the person you're replying to, but when they said "extraction" I believe they're talking about extracting pages from a PDF (like "splitting" the PDF apart, page-wise), not text. At least that's a thing I've used qpdf for in the past.
Which is also what the "extract" button does in Adobe Acrobat Pro DC for Professional Enterprise Customers or whatever they're calling it now, so it's arguably a term of art for PDFs.
There is also: https://pdfcpu.io/
That said, if you're looking for a GUI app to do simple PDF mutations it's often hard to fine a simple solid open source cross platform app.
At least I haven't found one :)
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.
Pdfsam and pdfxchange are my gotos
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.
pdf-xchange is worlds better for just about anything in my experience
can't believe I waited so long to try it out
TIL: there are numerous swiss army knifes for pdf files available already
Not the same thing but just want to shoutout https://www.pdfgear.com/ as one of the only viable alternatives to adobe for intermediate level PDF tinkering. It’s free and available for everything except Linux.
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?
Easy, just run your favorite Windows or Mac VM on any of that hardware and the corresponding PDFgear binary will work out of the box.
In 1994.
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.
They also say
I found it suspicious, they formerly sent stuff too their cloud without it being obvious, and the company seems to mod their own subreddit.
One feature I would love is the ability to automatically generate the table of contents / “outline” metadata for a pdf. I run across a lot of old book pdfs without that metadata, which makes navigation annoying. Kybook3 has a version of this that doesn’t quite work. Maybe in the age of LLMs, this is now feasible.
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.
Very nice! I’ll check it out.
I’m curious: what good would automating signing a PDF through a utility do?
The whole purpose of a signature is that a person signed and agreed to something. That cannot be done automatically.
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.
Also allowing you to detect whether any changes have been made since the signature was applied.
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.
Those don’t need certified signatures. They just need pdf stamps.
Just because that's what many people still do doesn't make it sane.
It depends on jurisdiction
Pdf stamps have zero security.
Signing can be cryptographic.
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.
In addition to the already mentioned, there is also pdfcpu[0], "a Go PDF processor and CLI"
[0]: https://github.com/pdfcpu/pdfcpu
I though Swiss Army knife for PDF are Didier Stevens PDF tools:
https://blog.didierstevens.com/programs/pdf-tools/
What about https://www.ghostscript.com ?
https://github.com/LibrePDF/OpenPDF
Pdftk has been been around for many years, and does exactly the same things. Why reinvent the wheel?
https://www.pdflabs.com/tools/pdftk-the-pdf-toolkit/
> 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’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”
The server component is under GNU GPL: https://www.pdflabs.com/docs/pdftk-license/
In case anyone gets confused, PDFTk Server is just the name for the CLI tool, which hasn't been updated in 10y+ (and annoying to compile due to newer GCC versions removing GCJ). The pdftk provided in various distros (incl. Debian, Fedora, Arch, NixOS) is pdftk-java, a 3rd-party pure Java port of the original tool.
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.
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.
This, is gorgeous! I absolutely hate the PDF ecosystem, and how painful it is to get a reasonably simple tool to just do basic edits to files (adding/removing pages, combining multiple PDFs etc). I particularly hate how hard it is to find good swiss army knives for it, and how you always land on sketchy websites to do simple things to a file.
This looks dead simple to use! LOVE IT.
The one feature request I have is for adjusting margins (adding/removing fixed amount of space from every page, optionally adding/removing different amounts from odd numbered pages). Target audience: People who want to read PDFs on small ebook readers.
I have similar tool its name TeX
Actually pdftex or luatex, but you are completely right, it can load a pdf file and do a lot of things with it.
Is this an alternative to acrobat?
due to the nature of PDF, none of the tools mentioned here can do things as simple as detecting tables on pages with high accuracy
PDF is absolutely mint for display but it really suffers when parsing is involved
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.
That's a good concept but I don't think Markdown is expressive enough for all the layouts & formatting that people typically want in PDFs. More likely that the source format would be something like HTML or SVG or .docx.
Restructured text has mostly 1:1 correspondence with Docbook. I use an XSLT transform to convert its XML schema into Docbook and PDF from there via XSL-FO.
This is totally an aside, but I wonder how long the "Swiss army knife" metaphor will hang on in popular culture. People generally use it to indicate that something does a variety of things, but I'd say many of younger generation have never touched if even seen such a knife in their life, and even among older generations it doesn't have a positive connotation.
Like when I hear something is the Swiss army knife of something, my take is that it does a lot of things poorly and there are better specific tools for every need. Like if you need a really terrible knife or bottle opener or screwdriver or saw, a Swiss Army knife has you covered. But it should be a tool of last resort when you have no other options.
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.
Be serious. If someone in 2025 has a pocket multitool, there's about a 1% chance it is red with a white cross on it.
??
Obviously it's not the only game in town ever since Leatherman made the pliers-style tool popular as well.
But you can just look up the various brands on Amazon to see that SAK's continue to sell very well, by "x bought in the last month."
It's nowhere near 1%, I don't know where you're getting that.
Edit: according to [1] Victorinox has the #1 spot in market share in multitools. The share is a bit higher than it is for SOG and Leatherman, though they're both close.
[1] https://www.marketreportanalytics.com/reports/swiss-army-kni...
I stand corrected.
Amazed, but corrected.
Lots of cheap (and good) Chinese alternatives entered the market recently but I'd say Victorinox is still going strong. In Poland it's sold everywhere and the brand is very recognizable.
Victorinox makes one of the better ones though theyre just pricey. I like my MXBS.
>Swiss Army knives seem to be as popular as ever.
It isn't as popular as ever, at least not in the Western world. I don't know what your frame of reference is, but it is positively non-existent compared to a couple of decades ago. Approximately zero kids, give or take a few, put one on their Christmas list, where when I was a kid it was many kid's dream item. I would say the most common buyer today are middle-aged men who buy it just as a thing to own because they remember how desirable they were when they were in Scouts in their teens.
>A tool of "last resort" seems to miss the point
It is quite literally a tool of last resort, and in practice people who actually own one (such as myself) have often never, ever actually used any of the options available on it because they're terrible options and we always have something better available.
Like a legitimate folding camping knife, which we all have in our camping supplies. An infinitely better knife. A tiny multi-screwdriver kit. The Leatherman brand went big by making a legitimately good, well constructed pair of pliers that they add some "in a pinch" options.
Serious campers who portage and go deep country have a proper assortment of gear and never lean on their SAK. The rest of us usually get there in a car and have a...proper assortment of gear.
But again, if you're in a situation where you have to use one of the tools on a SAK, you probably screwed up and it's a serious compromise. It just isn't a compelling metaphor for software tooling.
For me it's a bottle opener, a corkscrew and a knife that's good enough.
More picnic less camping in the wild.
See my other comment for its popularity statistics. Victorinox is literally the #1 multitool brand by market share. These are facts.
Your take is idiosyncratic. Using a SAK doesn't mean "you probably screwed up". That's truly a bizarre thing to say.
A SAK is a perfectly fine metaphor. That's why it's a popular one. It's a small tool that does lots of things. I think you're overthinking this.
>Victorinox is literally the #1 multitool brand by market share
This doesn't repudiate anything I said, and it's a particularly weird canard.
>That's why it's a popular one
Increasingly the only ones I see leveraging the metaphor are English as a second language writers (note that the idiom originates in English and is a calque in other languages) who perhaps came across it somewhere. I would hardly call it "popular", and I pointed out the reality that many readers, such as myself, find it a negative description, similar to someone calling themselves a "jack of all trades". Your defensiveness of SAK does not change this, and your attempts at invalidating my statement borders on bizarre.
Feel free to continue. I'm done here.
> are English as a second language writers who perhaps came across it somewhere
Your prejudice is showing. Where would you even get an idea like that?
I hope you understand that people whose first language isn't English also use SAKs. It's not just an English thing. They're not trying to repeat some unknown object they've only encountered in metaphor. The tools are literally Swiss. And popular around the entire world.
You’re absolutely right. I was just in Switzerland and I’ll tell you the Victorinox shops have endless visitors from all kinds of tourists. Swiss Army knife metaphor is timeless, at least for those who go out. Maybe there’s a generation where outdoor activities is an unknown because computers. At this point the other person is just being argumentative.
I'm being argumentative? Uproarious.
Arguing that my observations are invalid because you were in a Victorinox shop in Switzerland is the chef's kiss on this ridiculous discussion.
In the future, just move along. The other argumentative guy had no reason to get defensive about SAK, and this whole worthless discussion, from a basic observation about idioms and ill-suited tools, is a waste of bits.
> This doesn't repudiate anything I said, and it's a particularly weird canard.
It does repudiate it, directly. What are you on about?
It doesn't remotely repudiate anything I said, more than saying that Gpvos is the #1 seller of buggy whips ergo ipso facto buggy whips are super popular. This is not a hard logical chain to follow, so good god.
But secondly, even that site claimed they have what, a 20% marketshare of multitools from once owning the market entirely to themselves? Even if we were so profoundly simple that we believed that being the biggest vendor in a market validates the market, this particular example is hilarious.
If you opened the link, literally the first line says:
> The Swiss Army Knife (multi-tool) market, currently valued at $402 million in 2025
Nearing half a billion dollars doesn't sound like buggy whips to me.
And the bar chart clearly extrapolates the market continuing to grow. Not shrink.
But you still think the #1 brand in a large and growing market is "positively non-existent"...?
Again, for convenience:
https://www.marketreportanalytics.com/reports/swiss-army-kni...
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.
I'm not clear why you think the majority of sales were in airport shops.
Ring neck pillows, maybe.