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

61–70 of 100 posts

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

#61

Post by layer8 »

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…

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

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

#62

Post by eyegor »

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 ChatGPT API. We’re also experienced in optimizing technology usage to manage costs more effectively.

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

#63

Post by crazygringo »

llm_nerd wrote: post #56
gpvos wrote: post #54

Earlier quoted context omitted.

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

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

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

#64

Post by cratermoon »

montefischer wrote: post #55

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.

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

#65

Post by Gormo »

Hendrikto wrote: post #18
5- wrote: post #2

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

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

#66

Post by montefischer »

cratermoon wrote: post #64
montefischer wrote: post #55

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.

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

#67

Post by kevin_thibedeau »

apf6 wrote: post #58
WillAdams wrote: post #51

Earlier quoted context omitted.

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

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.

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

#68

Post by hackyhacky »

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.

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

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

#69

Post by lenerdenator »

hackyhacky wrote: post #68
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.

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

In 1994.

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

#70

Post by whizzter »

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

Post reply on HN