## 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<sub>PH</sub>, V<sub>IH</sub>, t<sub>PLH</sub>, I<sub>OZ</sub>... 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<sub>DD</sub>" 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.