Somewhere inside a PDF library, a 15-bit integer decides whether a railway drawing gets reviewed

The integer is 32,767, the largest value fifteen bits can hold. It is also the widest image, in pixels, that a common PDF renderer will produce. Railway drawings are wider than that. What happens next decides whether an engineer ever sees the page.

An engineer looking up at a concrete bridge spanning a river

A drawing fails at exactly 32,767 pixels

During a customer's initial sync, a handful of documents refused to ingest. They were not corrupt, and they were not password-protected. They were wide-format railway drawings: profiles and plans laid out along the track, pages designed to be printed a metre or more wide and read on a table. Our pipeline renders every PDF page to an image before anything else happens, at 288 DPI, high enough that dimension text and small annotations stay legible to the models reading them. A page 2.9 metres wide comes out at roughly 33,000 pixels.

That number matters because of how the rendering stack underneath us stores sizes. Poppler, the open-source PDF engine, draws pages through the graphics library cairo, and cairo caps image dimensions at 32,767 pixels: the largest value a signed 16-bit integer can hold, one bit for the sign and fifteen for the number. A page that needs 33,000 pixels does not come out slightly cropped. It does not come out at all. And in our first version, that one page took the whole file with it. A drawing set could contain forty pages that rendered perfectly, and the reviewer got none of them.

Degrade the page, never fail the file

The tempting answer is to lower the resolution everywhere and move on. That trades away the very thing the rendering exists for: legible text on ordinary pages, which are the overwhelming majority. The fix that held is a pixel budget: a cap on how many pixels a page may cost, regardless of how wide it is, with the resolution computed per page to stay under it. Around the budget sits a ladder. Each rung gives up a little. No rung gives up the file.

Step What happens What is lost
1 The page renders at standard resolution Nothing
2 The page is re-rendered under a fixed pixel budget, at lower resolution for that page only Some sharpness, on that page
3 The page is skipped; every page that renders is kept One page
4 The document falls back to plain text extraction Layout and graphics; the text survives

The ladder follows a rule we now treat as the first law of ingestion:

Klassificera och degradera, faila aldrig filen.

The ingestion rule, as it is written internally. "Classify and degrade, never fail the file."

Behind the rule sits an observation that sounds like superstition but is a selection effect: the file that crashes the pipeline is always the one the reviewer needs. Documents that follow the template render cleanly, because templates are what rendering stacks get tested against. The files that break are the ones that deviate: the three-metre drawing, the scanned annex, the spreadsheet exported sideways. Deviation is also where the review risk lives. Drop the awkward files and you have not lost random pages. You have systematically lost the interesting ones. For a reviewer, the worst outcome is not a blurry page. It is a page that disappears without a word.

An invisible space breaks every Swedish number

The second specimen is smaller than a pixel. Swedish documents write large numbers with spaces as thousands separators: 1 000 000. Authoring tools insert those separators as non-breaking spaces (U+00A0) or narrow no-break spaces (U+202F), so the number never breaks across a line. In a tender package that covers nearly every quantity, every limit value and every sum. After PDF extraction the characters are everywhere in the text, and they are visually identical to an ordinary space.

Identical to the eye. Different to the machine. A pattern looking for amounts fails silently. Deduplication decides that 1 000 and 1 000 are two different strings, because in bytes they are. A requirement quoted back against the tender documents no longer matches its own source. Nothing throws an error anywhere; the results just get quietly worse. The fix is a normalization pass that runs before anything else touches the text: a few lines of code, the least glamorous change in the codebase, and it moved measured accuracy more than most of the model work around it.

The layer under the demo

"AI reads your documents" is one sentence in a product description. Underneath it sit a pixel budget, a degradation ladder, a Unicode normalization pass and a hundred other decisions of the same size. None of them show well in a demo. All of them set the ceiling, because the model never gets a chance to be right about a page that never rendered, or a number it received with the wrong bytes.

Yesper is the AI civil engineer for construction and infrastructure, and a surprisingly large share of building one looks exactly like this. Somewhere inside a PDF library, a 15-bit integer decides whether a railway drawing gets reviewed. Our job is to make sure it decides in the reviewer's favour.

Benjamin Glaser Co-founder at Yesper. Writes about AI and the industry that builds the world. benjamin@yesper.ai

Yesper is the AI civil engineer for construction and infrastructure. AFRY, COWI, NRC Group and other Nordic firms use it to halve the time on a study, rerun calculations in minutes, and catch errors that would otherwise slip through. Get in touch if you'd like to see what it can do for you.

Book demo