The hard 20% of PDF extraction (and why every tool handles it differently)

Direct answer: Every PDF extractor — pdfmux included — gets the easy majority of documents right: clean, single-column, digitally-authored text. The disagreements start on the harder slice: multi-column magazine and academic layouts, tables that span a page break, documents that mix scanned and native pages, PDFs with non-standard or custom-encoded fonts, and scans that come in rotated or skewed. No two tools fail on that slice the same way, because each one was built around different assumptions about which case matters most. This is a tour of those failure modes, how pdfmux’s routing approach handles each one, and — just as importantly — which parts of this remain genuinely unsolved for everyone, pdfmux included.

The part nobody disagrees about

Feed any modern extractor a clean, single-column, digitally-generated PDF — an invoice, a simple report, a contract with no exotic formatting — and you’ll get a usable result back from almost any tool on the market. That’s not a controversial claim; it’s why benchmark leaderboards cluster so tightly on “typical” documents. The interesting question was never “does it work on the easy case.” It’s what happens on the slice of real-world documents that aren’t that: the multi-column research paper, the financial filing with a table that runs onto the next page, the archive scan with a few native pages mixed in. That’s the harder 20%, and it’s where tool choice actually matters.

Multi-column and magazine layouts

A PDF doesn’t store “paragraphs” or “columns” — it stores a sequence of text-drawing instructions, in whatever order the authoring tool happened to emit them. On a single-column page that order usually matches reading order, which is exactly why naive extraction looks reliable right up until it meets a two-column academic paper or a magazine spread with sidebars. Read the raw text stream on one of those and you get a line from the left column, a line from the right, back to the left — a sentence sliced mid-thought into an unrelated one. It never throws an error. It just quietly hands a RAG pipeline garbage that reads fine on a skim and answers questions wrong.

pdfmux detects column structure before it serializes a page — clustering word positions to find the column boundaries, then emitting each column in full before moving to the next — rather than emitting text in file order and hoping it matches what a human would read.

Tables that span a page break

A table that fits on one page is a solved problem industry-wide. A table that runs across a page break is where most tools quietly diverge: treat each page independently and you get two separate tables with a repeated header, not one. Whether a tool merges those halves back into a single structure — and whether it tells you when it isn’t sure the merge was clean — is the actual differentiator, not whether it can read a table at all.

pdfmux’s table handling is built to recognize a continuation (a repeated header row, consistent column structure across the page boundary) and stitch it back into one table rather than returning two fragments. This is also one of the places we’re not going to overstate our own result: table completeness across a page break is a hard case industry-wide, and we treat it as an open problem rather than a solved one — see the caveats on our own compare page for exactly where that line sits today.

Scanned and native pages in the same document

Real-world archives rarely come as cleanly “all scanned” or “all digital.” A contract that was signed on paper and then the signature page re-scanned into an otherwise-digital PDF. A government filing where pages 12 through 15 were faxed in. A single wrong assumption — treat the whole document as scanned, or treat it all as digital — either wastes time running OCR on text that was already extractable, or returns empty text for the pages that needed OCR and never tells you.

pdfmux classifies each page individually (digital text layer present vs. not) and routes each one to the appropriate path — direct extraction for native pages, OCR for scanned ones — rather than making one global decision for the whole file.

Non-standard and custom-encoded fonts

Some of the ugliest extraction failures look nothing like a failure. A PDF that embeds a subset of a font — only the glyphs the document actually uses — maps character codes to glyph IDs internally, and is supposed to ship a mapping back to real Unicode alongside it. When that mapping is missing or malformed, you get text back that looks like a successful extraction: real-looking characters, correct-looking spacing — except the characters are wrong. It’s quieter than a blank page, and often more dangerous, because nothing about the output looks broken until someone reads it closely.

This is a case where we’re explicit about the limits: a page that re-derives as garbled from a bad font mapping doesn’t always announce itself the way a missing table or an empty scanned page does, which is exactly why pdfmux’s per-page review is there as a second check rather than something you skip because extraction “ran successfully.”

Rotated and skewed scans

A flatbed scanner produces straight pages. A photographed document, a fax, or a scan fed in slightly crooked does not — and OCR engines are far more sensitive to a few degrees of rotation than most people expect. A page that looks readable to a human can still return a badly fragmented OCR result if it isn’t straightened first.

pdfmux’s OCR path includes a deskew step before text recognition runs, specifically because skipping it is one of the most common causes of OCR output that’s technically present but practically unusable.

Nested and merged table cells

Tables with merged cells, nested headers, or irregular row spans are a genuinely different problem from tables with a clean grid — recovering the structure requires understanding that a cell spans multiple columns or rows, not just that text exists at a coordinate. Some tools specialize here more deeply than others; where a document’s whole job is recovering that structure precisely, routing to a specialist table model is often the more honest answer than asking a general-purpose text extractor to guess at it.

This is exactly the kind of case pdfmux’s routing exists for: rather than claiming one default backend is the best choice for every document, it can send table-heavy pages to the backend built for that job.

What’s still hard for everyone, including pdfmux

The honest version of “the hard 20%” admits that some of it stays hard. Table completeness across irregular layouts remains an open problem, not a solved one, on our own compare page. Font-mapping recovery on badly subsetted or custom-encoded fonts doesn’t always succeed. Right-to-left and mixed-script documents introduce their own reading-order questions that are a different problem from column detection. None of these are unique to pdfmux — they’re the actual edge of what any current extraction approach can promise — and we’d rather name them than let a clean demo document imply they’re solved.

Where this leaves you

If your pipeline only ever sees simple, single-column, digitally-authored PDFs, the tool you pick for extraction barely matters — they mostly agree. The moment real-world documents show up — mixed scans, multi-column layouts, tables that don’t fit on one page — the differences stop being theoretical. pdfmux’s approach is to classify each page and route it rather than assume one backend is right for everything, and to say plainly where that routing still comes up short.

Try it: pip install pdfmux && pdfmux convert document.pdf. For the architecture behind the routing decisions, see what “self-healing” PDF extraction actually looks like; for the reading-order problem specifically, see extracting multi-column PDFs in the right order; and for how this fits into a retrieval pipeline, see PDF to Markdown for RAG.