Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Spotlight on pdfly, the Swiss Army knife for PDF files

chezsoi.org

Post reply on HN
Print view View original

71–80 of 100 posts

Re: Spotlight on pdfly, the Swiss Army knife for PDF files

#71

Post by conradev »

JackC wrote: post #50

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 ge…

  The ecosystem would be greatly improved if someone made a great (probably rust based) in-memory low level pdf reading and writing data structure.
https://github.com/J-F-Liu/lopdf

Re: Spotlight on pdfly, the Swiss Army knife for PDF files

#72

Post by zehaeva »

JackC wrote: post #50

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 ge…

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/

Re: Spotlight on pdfly, the Swiss Army knife for PDF files

#73

Post by whenc »

whizzter wrote: post #70
JackC wrote: post #50

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 ge…

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 ide…

You can do:

  cpdf -output-json in.pdf -o out.json
(Modify out.json as liked)

  cpdf -j out.json -o out.pdf
(Disclaimer, I wrote it.)

Re: Spotlight on pdfly, the Swiss Army knife for PDF files

#74

Post by darkwater »

eyegor wrote: post #62
theothertimcook wrote: post #16

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 Chat…

They also say

    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.

Re: Spotlight on pdfly, the Swiss Army knife for PDF files

#75

Post by emeril »

phyalow wrote: post #10
jopsen wrote: post #3

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 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

Re: Spotlight on pdfly, the Swiss Army knife for PDF files

#76

Post by IAmBroom »

crazygringo wrote: post #33
IAmBroom wrote: post #32

Earlier quoted context omitted.

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…

I stand corrected.

Amazed, but corrected.

Re: Spotlight on pdfly, the Swiss Army knife for PDF files

#77

Post by IAmBroom »

pseingatl wrote: post #30
llm_nerd wrote: post #27

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 some…

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.

Re: Spotlight on pdfly, the Swiss Army knife for PDF files

#78

Post by forgotpwd16 »

mkesper wrote: post #43
moopie wrote: post #28

Earlier quoted context omitted.

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.

Re: Spotlight on pdfly, the Swiss Army knife for PDF files

#79

Post by specialist »

JackC wrote: post #50

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 ge…

> 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.

Re: Spotlight on pdfly, the Swiss Army knife for PDF files

#80

Post by [deleted] »

forgotpwd16 wrote: post #78
mkesper wrote: post #43

Earlier quoted context omitted.

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.

[deleted]
Post reply on HN