So you want to parse a PDF? • Hacker News Board

Re: So you want to parse a PDF?

#11

Post by UglyToad » Mon, Aug 04, 2025, 12:03 AM UTC

farkin88 wrote: post #8

Great rundown. One thing you didn't mention that I thought was interesting to note is incremental-save chains: the first startxref offset is fine, but the /Prev links that Acrobat appends on successive edits may point a few bytes short of the next xref. Most viewers (PDF.js, MuPDF, even Adobe Reader in "repair" mode) fall back to a brute-force scan for obj tokens and reconstruct a fresh table so they work fine while…

You're right, this was a fairly common failure state seen in the sample set. The previous reference or one in the reference chain would point to offset of 0 or outside the bounds of the file, or just be plain wrong.

What prompted this post was trying to rewrite the initial parse logic for my project PdfPig[0]. I had originally ported the Java PDFBox code but felt like it should be 'simple' to rewrite more performantly. The new logic falls back to a brute-force scan of the entire file if a single xref table or stream is missed and just relies on those offsets in the recovery path.

However it is considerably slower than the code before it and it's hard to have confidence in the changes. I'm currently running through a 10,000 file test-set trying to identify edge-cases.

[0]: https://github.com/UglyToad/PdfPig/pull/1102

Re: So you want to parse a PDF?

#12

Post by UglyToad » Mon, Aug 04, 2025, 12:08 AM UTC

simonw wrote: post #6

I convert the PDF into an image per page, then dump those images into either an OCR program (if the PDF is a single column) or a vision-LLM (for double columns or more complex layouts). Some vision LLMs can accept PDF inputs directly too, but you need to check that they're going to convert to images and process those rather than attempting and failing to extract the text some other way. I think OpenAI, Anthropic and…

If you don't have a known set of PDF producers this is really the only way to safely consume PDF content. Type 3 fonts alone make pulling text content out unreliable or impossible, before even getting to PDFs containing images of scans.

I expect the current LLMs significantly improve upon the previous ways of doing this, e.g. Tesseract, when given an image input? Is there any test you're aware of for model capabilities when it comes to ingesting PDFs?

Re: So you want to parse a PDF?

#13

Post by internetter » Mon, Aug 04, 2025, 12:09 AM UTC

throwaway840932 wrote: post #7

As a matter of urgency PDF needs to go the way of Flash, same goes for TTF. Those that know, know why.

I think a PDF 2.0 would just be an extension of a single file HTML page with a fixed viewport

Re: So you want to parse a PDF?

#14

Post by sergiotapia » Mon, Aug 04, 2025, 12:12 AM UTC

I did some exploration using LLMs to parse, understand then fill in PDFs. It was brutal but doable. I don't think I could build a "generalized" solution like this without LLMs. The internals are spaghetti!

Also, god bless the open source developers. Without them also impossible to do this in a timely fashion. pymupdf is incredible.

https://www.linkedin.com/posts/sergiotapia_completed-a-reall...

Re: So you want to parse a PDF?

#15

Post by diptanu » Mon, Aug 04, 2025, 12:13 AM UTC

Disclaimer - Founder of Tensorlake, we built a Document Parsing API for developers.

This is exactly the reason why Computer Vision approaches for parsing PDFs works so well in the real world. Relying on metadata in files just doesn't scale across different source of PDFs.

We convert PDFs to images, run a layout understanding model on them first, and then apply specialized models like text recognition and table recognition models on them, stitch them back together to get acceptable results for domains where accuracy is table stakes.

Re: So you want to parse a PDF?

#16

Post by rkagerer » Mon, Aug 04, 2025, 12:19 AM UTC

diptanu wrote: post #15

Disclaimer - Founder of Tensorlake, we built a Document Parsing API for developers. This is exactly the reason why Computer Vision approaches for parsing PDFs works so well in the real world. Relying on metadata in files just doesn't scale across different source of PDFs. We convert PDFs to images, run a layout understanding model on them first, and then apply specialized models like text recognition and table recogn…

So you've outsourced the parsing to whatever software you're using to render the PDF as an image.

Re: So you want to parse a PDF?

#17

Post by bee_rider » Mon, Aug 04, 2025, 12:22 AM UTC

rkagerer wrote: post #16

diptanu wrote: post #15

Disclaimer - Founder of Tensorlake, we built a Document Parsing API for developers. This is exactly the reason why Computer Vision approaches for parsing PDFs works so well in the real world. Relying on metadata in files just doesn't scale across different source of PDFs. We convert PDFs to images, run a layout understanding model on them first, and then apply specialized models like text recognition and table recogn…

So you've outsourced the parsing to whatever software you're using to render the PDF as an image.

Seems like a fairly reasonable decision given all the high quality implementations out there.

Re: So you want to parse a PDF?

#18

Post by throwaway4496 » Mon, Aug 04, 2025, 12:24 AM UTC

diptanu wrote: post #15

Disclaimer - Founder of Tensorlake, we built a Document Parsing API for developers. This is exactly the reason why Computer Vision approaches for parsing PDFs works so well in the real world. Relying on metadata in files just doesn't scale across different source of PDFs. We convert PDFs to images, run a layout understanding model on them first, and then apply specialized models like text recognition and table recogn…

So you parse PDFs, but also OCR images, to somehow get better results?

Do you know you could just use the parsing engine that renders the PDF to get the output? I mean, why raster it, OCR it, and then use AI? Sounds creating a problem to use AI to solve it.

Re: So you want to parse a PDF?

#19

Post by Alex3917 » Mon, Aug 04, 2025, 12:24 AM UTC

diptanu wrote: post #15

Disclaimer - Founder of Tensorlake, we built a Document Parsing API for developers. This is exactly the reason why Computer Vision approaches for parsing PDFs works so well in the real world. Relying on metadata in files just doesn't scale across different source of PDFs. We convert PDFs to images, run a layout understanding model on them first, and then apply specialized models like text recognition and table recogn…

> This is exactly the reason why Computer Vision approaches for parsing PDFs works so well in the real world.

One of the biggest benefits of PDFs though is that they can contain invisible data. E.g. the spec allows me to embed cryptographic proof that I've worked at the companies I claim to have worked at within my resume. But a vision-based approach obviously isn't going to be able to capture that.

Re: So you want to parse a PDF?

#20

Post by throwaway4496 » Mon, Aug 04, 2025, 12:25 AM UTC

bee_rider wrote: post #17

rkagerer wrote: post #16

Earlier quoted context omitted.

So you've outsourced the parsing to whatever software you're using to render the PDF as an image.

Seems like a fairly reasonable decision given all the high quality implementations out there.

How is it reasonable to render the PDF, rasterize it, OCR it, use AI, instead of just using the "quality implementation" to actually get structured data out? Sounds like "I don't know programming, so I will just use AI".