How we give every document a transcript

A flipbook is a stack of pictures. That is the quiet embarrassment of most of them — lovely, page-turning pictures that a screen reader, a search box, and Google all see as completely blank.

We didn’t want to ship that. So every document on Living Page carries a text transcript of every page, sitting invisibly behind the images. Getting there was more interesting than it sounds, because PDFs come in two very different flavours.

The easy half

Most PDFs are born digital — exported straight from a design tool or a word processor. They look like pages, but underneath they still carry the actual text, positioned invisibly over the artwork. You just have to know it’s there.

That half is close to free. When we convert a document, we already open every page to render it into a crisp image for the reader. While the page is open, we lift the text out at the same time. One pass, two outputs: the picture you see, and the words behind it. Every born-digital page has its transcript the moment it finishes converting.

The hard half

Then there are scanned documents — a contract someone photographed, an old brochure run through an office scanner, a menu that started life on paper. To a computer these aren’t words at all. They’re a photograph of words. There is nothing to lift out, because there is nothing there.

The only way to get text back is to read the picture — optical character recognition. And this is where we made a deliberate choice. Traditional OCR engines are decades old and brilliant on clean, straight, high-contrast scans — and they fall apart on the real world: a slight skew, a coffee-cup shadow, a table, an unusual typeface. Real documents are messy. So rather than a classic OCR library, we hand image-only pages to a modern vision AI model and ask it to read them. On the kind of scans people actually upload, the quality difference wasn’t subtle — and that decided it.

(How exactly we do that is the part I’ll keep behind the curtain. This is a behind-the-scenes post, not a build guide.)

The decision that actually mattered

Here’s the bit worth stealing, whatever you’re building.

Reading a scanned page is slow — far slower than rendering an image. If we made every upload wait for it, a 60-page scanned catalogue would leave someone staring at a spinner while we laboured through every page.

So we don’t. The document goes live immediately — all its images, plus whatever text we already have. The reading-the-pictures work happens afterwards, as a quiet background pass, filling the transcripts in behind the reader while it’s already open. By the time most people have flicked to the later pages, the words are usually already there.

And it’s strictly best-effort. If a particular page won’t read cleanly, nothing breaks and nobody waits — the reader simply falls back to the image, exactly as before.

The general lesson: never make the fast, essential thing wait on the slow, optional one. Ship the page, then let the nice-to-have catch up in the background. Users feel the first part and rarely notice the second.

Why bother at all

Three reasons, and only one of them is obvious.

• Accessibility. A screen reader gets real words instead of silence. If you send documents for a living, some of the people receiving them can’t read a flat image — and usually nobody tells you, they just go quiet.
• Search. You can find a document by what’s inside it, not just its title.
• It’s the difference between a flipbook that looks alive and one that actually is. A page you can read, search, and hear is a living page. A photograph of a page is just a photograph.

That last one is the whole point, really. Anyone can turn a PDF into pictures. Making it readable — to a person, a screen reader, and a search box alike — is the work.