The problem

We have a PDF (well.. we have many of them!) and we want text out of it. The obvious move is to run a text extractor — pdftotext, markitdown, whatever ships in our stack. For a decent fraction of PDFs, that works, and it's fast and free. So why does Estravon reach for a vision-language model instead of doing the obvious cheap thing?

But "a decent fraction" is not "all"... moreover the PDFs where a text extractor fails are the ones researchers care about most: scanned book chapters, older papers, anything with tables, figures, multi-column layout, or mathematical notation!

Datasheets, a real nightmare

As exampe datasheets are close to a worst case for plain text extraction, worse than most patents or book chapters.

Parametric tables (electrical characteristics, absolute maximum ratings) are the entire value of the document. These are dense grids of min/typ/max values keyed to symbols like I_PH, V_IH, t_PLH, I_OZ... Column misalignment here doesn't just look ugly, it silently swaps which number belongs to which parameter.. a real bug!

Pinout diagrams and package drawings are vector graphics with number/label callouts. There's no text-layer path to "pin 14 is V_DD" at all. Only a layout-aware model (or true VLM reading the image) can associate the two. Multi-column body text with footnotes and revision-history tables at small point size.

Most datasheets are born-digital (FrameMaker/InDesign/LaTeX-style tooling from Analog Devices, TI, ST, etc.), so a text layer is almost always present.. this isn't a scanned-document problem like old patents. But presence of a text layer barely helps here, because the failure mode isn't OCR error, it's structural: tables and diagrams, not prose.

What's actually happening

A text extractor reads the text layer a PDF claims to have. When that layer is faithful, you get clean output. But the text layer can be:

• Absent — a scanned page is just an image; there is no text to extract, and a naive extractor returns nothing (or a blank).
• Wrong — ligature and encoding quirks turn fi into a missing glyph, or scramble the reading order of a two-column layout into interleaved nonsense.
• Structurally flat — a table becomes a run-on line; a figure caption floats away from its figure; an equation becomes s i n with the spacing of the rendered glyphs baked in.

A VLM reads the rendered page — what a human sees — and reconstructs structure from layout. It costs more per page, but it degrades gracefully on exactly the inputs where a text extractor degrades catastrophically.

What we do about it

Estravon it runs a VLM because the failure mode of the cheap path is silent. A text extractor that returns scrambled text doesn't raise any error , it hands us plausible-looking output that's quietly missing half a table.

For our research workflow, a silent wrong answer is way worse than a loud failure: we risk to use the info (..or cite it :( ..) without knowing.

Open question

Here's the part I'd like to research further: how would you detect a silent extraction failure automatically? Given only the input PDF and the extractor's output, no ground truth, what signal tells you the text layer lied? Round-trip rendering? A confidence score from the model? Cross-checking two extractors against each other? If you've built something that works, I want to hear it.