So you want to parse a PDF? (eliot-jones.com)

Yeah, PDF didn't anticipate streaming. That pesky trailer dictionary at the end means you have to wait for the file to fully load to parse it.

Having said that, I believe there are "streamable" PDF's where there is enough info up front to render the first page (but only the first page).

(But I have been out of the PDF loop for over a decade now so keep that in mind.)

> So you want to parse a PDF?

Absolutely not. For the reasons in the article.

One of the very first programming projects I tried, after learning Python, was a PDF parser to try to automate grabbing maps for one of my DnD campaigns. It did not go well lol.

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 Gemini all do the images-version of this now, thankfully.

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

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 a spec-accurate parser explodes. Building a similar salvage path is pretty much necessary if you want to work with real-world documents that have been edited multiple times by different applications.

I parsed the original Illustrator format in 1988 or 1989, which is a precursor to PDF. It was simpler than today's PDF, but of course I had zero documentation to guide me. I was mostly interested in writing Illustrator files, not importing them, so it was easier than this.

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

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.

Thanks kindly for this well done and brave introduction. There are few people these days who'd even recognize the bare ASCII 'Postscript' form of a PDF at first sight. First step is to unroll into ASCII of course and remove the first wrapper of Flate/ZIP,LZW,RLE. I recently teased Gemini for accepting .PDF and not .EPUB (chapterized html inna zip basically, with almost-guaranteed paragraph streams of UTF-8) and it lamented apologetically that its pdf support was opaque and library oriented. That was very human of it. Aside from a quick recap of the most likely LZW wrapper format, a deep dive into Lineariziation and reordering the objects by 'first use on page X' and writing them out again preceding each page would be a good pain project.

UglyToad is a good name for someone who likes pain. ;-)

As someone who has written a PDF parser - it's definitely one of the weirdest formats I've seen, and IMHO much of it is caused by attempting to be a mix of both binary and text; and I suspect at least some of these weird cases of bad "incorrect but close" xref offsets may be caused by buggy code that's dealing with LF/CR conversions.

What the article doesn't mention is a lot of newer PDFs (v1.5+) don't even have a regular textual xref table, but the xref table is itself inside an "xref stream", and I believe v1.6+ can have the option of putting objects inside "object streams" too.

I remember having a prior boss of mine asked if the application the company I was working for made could use PDF as an input. His response was to laugh then say "No, there is no coming back from chaos." The article has only reinforced that he was right.

This is one of those things that seems like it shouldn't be that hard until you start to dig in.

See https://digitalcorpora.org/corpora/file-corpora/cc-main-2021... for a set of 8 million PDF files from the web, as seen by a single crawl of Common Crawl.

founder of mixpeek here, we fine-tune late interaction models on pdfs based on domain https://mixpeek.com/extractors

Last weekend I was trying to convert some PDF of Upanishads which contains some Sanskrit and English word.

By god its so annoying, I don't think I would be able to without the help of Claude Code with it just reiterating different libraries and methods over and over again.

Can we just write things in markdown from now on? I really, really, really, don't care that the images you put is nicely aligned to the right side and every is boxed together nicely.

Just give me the text and let me render it however I want on my end.

Can you just ignore the index and read the entire file to find all the objects?

The answer seems obvious to me:

   1. PDFs support arbitrary attached/included metadata in whatever format you like.
   2. So everything that produces PDFs should attach the same information in a machine-friendly format.
   3. Then everyone who wants to "parse" the PDF can refer to the metadata instead.

From a practical standpoint: my first name is Geoff. Half the resume parsers out there interpret my name as "Geo" and "ff" separately. Because that's how the text gets placed into the PDF. This happens out of multiple source applications.

pdfgrep (as a command line utility) is pretty great if one simply needs to search text in PDF files https://pdfgrep.org/

Other PDF parsing woes include:

1. Identifying form elements like check boxes and radio buttons. 2. Badly oriented PDF scans 3. Text rendered as bezier curves 4. Images embedded in a PDF 5. Background watermarks 6. Handwritten documents

PDF parsing is hell indeed: https://unstract.com/blog/pdf-hell-and-practical-rag-applica...

Docling* works pretty well in PDF hell, but is terribly slow.

*https://docling-project.github.io/docling/

Those of you saying OCR and Vision LLM are missing the point.

This is an article by a geek for other geeks. Not aimed at solution developers.

> Assuming everything is well behaved and you have a reasonable parser for PDF objects this is fairly simple. But you cannot assume everything is well behaved. That would be very foolish, foolish indeed. You're in PDF hell now. PDF isn't a specification, it's a social construct, it's a vibe. The more you struggle the deeper you sink. You live in the bog now, with the rest of us, far from the sight of God.

This put a smile on my face:)

PDF is a format for preserving layouts across different platforms when viewing and printing. It is not intended for data processing and so on. I don't see why a structured document format can't exist that simplifies processing and increases accessibility while still preserving the layouts.