The Slide Deck Check That Read Four-Pixel Text

Posted by:

|

On:

|

Our own slide check looked at the thumbnails and reported no problems. The thumbnails were small, the body text inside them stood four pixels high, and the check had a rule about declared font sizes rather than about pixels. Every slide passed. In the room, half the slide deck was unreadable from row ten, signed off by a gate that never opened the surface the audience would see.

What we assumed a slide deck check was checking

We assumed the risk in building slides from a document was design: uneven spacing, a template applied inconsistently, colours that fight. So the check read the markup. It could see a declared type size, a class name, a template’s font scale, and compared those against a floor. On paper that is a legibility check. In practice it verifies that a stylesheet contains the number we told it to look for.

A declared size and a rendered size are not the same quantity. A container constraint, a scaling transform, a font that failed to load — any of them collapses the glyph while the declaration sits where it was written. Our check read the declaration back to itself and agreed. The four-pixel text was in the picture the whole time; nothing in the pipeline had opened the picture.

The second assumption was quieter. Every slide carried an anchor: a claim, a span ID, a verbatim excerpt. The anchors resolved — each excerpt was found in the source document. We read that as traceability. It was a substring search across a whole file.

Two failures with one shared property

Density and traceability are separate problems that broke the same way: both were measured on a convenient surface rather than the one where the failure lives.

For density the real surface is the raster: an image of the slide at the resolution the room will show it at. What matters there is the pixel height of actual lowercase ink, smaller than the em box holding it by roughly the x-height ratio of the face being shipped. A 24 pt minimum on a slide 540 pt tall is a 48-pixel em box on a 1080-pixel render, and a face putting about half its em into ink leaves around 24 pixels — a ratio of 1:45, not the 1:22.5 the type size suggests. State the floor in the quantity you measure. A ratio survives a change of resolution; a pixel threshold does not, and a type-size floor compared against a measured ink height condemns every slide for nothing.

The thumbnail is the seductive form of the mistake. It is a picture, and genuinely a render. It is just not the render anyone will look at, and every number taken from it is wrong by whatever factor separates it from delivery resolution.

An anchor that points at a document proves nothing

Traceability has the same shape. The convenient surface is the document; the failure lives in the span. If a slide cites one span and the excerpt turns up inside a different paragraph, the words exist and the citation is false — both at once. A whole-file search cannot tell those apart. It returns a hit, the table prints anchored, and the build proceeds.

The hit has to land inside the byte range of the cited span: that is the difference between evidence and a status code.

Drift survives even a correct anchor. A number rounded the wrong way still points at a real passage, in the right span, through a genuine excerpt. The link check passes because the link is real; what broke is the claim, not the pointer. Every proper noun, number, unit and date on a slide has to be checked against the span itself, not against the fact that a span was named.

What follows for anyone generating a slide deck

Two rules, both narrow. Measure on the surface the reader sees — for a deck that means a retained raster at delivery resolution, with the renderer and its version written down, because a measurement whose surface has been discarded cannot be rechecked. And make a citation point at a place rather than a document: an offset inside a stated range.

One consequence gets resisted. When a claim will not fit, splitting it is the only move available. Shrinking the type converts a problem you can see into one you cannot, and that conversion produced our four-pixel text. An overflow you can see is a bug; an overflow you solved by shrinking is a bug you shipped.

The budget has to come from the room, not the deck: a ceiling derived from the longest slide already drafted is exceeded by nothing. And both halves must emit numbers. A slide that passed without a recorded character count, ink height and byte offset was not measured, it was described.

Legibility and traceability give no coverage of each other. A readable slide can misquote its source and an anchored slide can be illegible, so a slide deck build that reports one is silent about the other.

The runnable procedure — the freezing of spans, the derivation of the budget, and the guards that catch these failures — lives in the member library.

How we know

Grounded in: our own deck builds behind deck-from-source v1.1, 2026-09-04 — a slide check that inspected thumbnails in which body text stood four pixels high and reported every slide in order, and anchors that resolved against the whole source document instead of the cited span. Verified: slides were re-rendered at delivery resolution and the smallest lowercase ink height measured on the image, and each excerpt was string-matched with its offset compared against the byte range of the span it cited. The runnable procedure lives in the member library.

Leave a Reply

Your email address will not be published. Required fields are marked *