fix(html): scale the text with the fit, where webkit holds it back

[andiwand]

🤖 Generated with Claude Code

Closes #761.

What was wrong

Not the meta tag, and not the script failing to run. In fit_width_by_view on iOS the view does fit: body{zoom:0.4867} is applied, odr.getZoom() returns 0.49, the A4 page box lands at the screen width. The type does not follow.

Webkit reads a css zoom as a scale the reader asked for and holds text at the size it would have had without one. It expresses that through text-size-adjust, dividing the stated percentage by the zoom:

text-size-adjust under zoom:k	used font size
auto — the default, and what we ship	inflated by a factor its cluster heuristics pick; 12pt → 47px in the sample
none or 100%	inflated by exactly 1/k
k·100%	the specified size

So #761's "heading unchanged, body text ~2×, reflowed" is a correctly fitted page with the text left behind. The same held for odr.setZoom, which was equally wrong on iOS.

The change

viewport_js states the zoom back as the percentage whenever it applies one. Blink reads the same percentage as a plain multiplier — 50% under zoom:0.5 halves the text a second time — so a probe at startup measures whether stating it holds the type, and it is only stated where it does. @media print resets it beside the zoom.

apply() and the startup block go through one zoomBody, which also restates a zoom the css stated (viewport_width, initial_zoom), so those pages carry the adjustment too.

Measured

iPhone 17 Pro / iOS 26 simulator, Pixel 9 Pro / Chrome 139 emulator, desktop Chrome, macOS WebKit — a WKWebView harness serving the emitted html, plus test/browser/viewport.

--odr-fit:view, the sample ODT, after:

viewport	zoom	stated	font sizes
402	0.487	48.67%	12pt→16px, 16pt→21.3px, 26pt→34.7px
600	0.726	72.64%	all exact
874	1	100%	all exact

• Android: probe declines, text-size-adjust stays auto, page fitted, type exact — unchanged.
• Desktop Chrome: tests.html all passed; both top-level banners PASS.
• macOS WebKit: both top-level banners PASS. The property does not exist there.
• odr_test --gtest_filter='html*:*Html*': 346 passed, 6 pre-existing skips.

Reference output

The print rule and viewport.js changed, so every emitted document moves by that one rule — on screen nothing does. compare-html --driver chrome over the private corpus: the differing set is not reproducible run to run (4, then 3, then 1 file, same pair of trees), and splitting the change proves it — the reference against the new script alone matches all files, the print rule alone flakes. Pre-existing rasterisation noise, not this change.

Regenerated anyway, so the reference stays what the renderer emits:

• private — regenerated, 1239 files, one line each, plus resources/viewport.js; nothing else moved. Pushed as bcea37b, and test/data.cmake advances to it.
• public — not touched. Its output main is at d456f47, the regen for the unlanded docx: a floating drawing renders inline, and a table's borders are dropped unless they sit on the cell #803, so a regen from this branch would revert docx: a floating drawing renders inline, and a table's borders are dropped unless they sit on the cell #803's docx output, and pinning a commit that contains docx: a floating drawing renders inline, and a table's borders are dropped unless they sit on the cell #803 would fail CI on a main that has no docx: a floating drawing renders inline, and a table's borders are dropped unless they sit on the cell #803. Its pin stays at 3dcc4fb; the reference renders identically to what this branch emits, so CI is green either way, and docx: a floating drawing renders inline, and a table's borders are dropped unless they sit on the cell #803 picks the rule up in its own regen.

Two findings not acted on here

1. Webkit draws no text below 9 css px, and text-size-adjust cannot defeat it (16px at zoom:0.25 → 36px; 40px → 40px). At the deepest fits this floors table text — 12pt at zoom 0.487 renders at 9px instead of 7.8px, laying the sample out 9% taller. Non-table text is unaffected.
2. Already shipping, separate: in automatic mode on iOS, webkit boosts body text — 12pt → 23px, 16pt → 24px, the sample 1949px tall against 1702px. iOS renders therefore do not match the reference renders. A static text-size-adjust:100% in the shipped css fixes it and is a measured no-op in Blink, but it also makes an A4 page's body text genuinely tiny on a phone, so it is left out of a bug fix.

Not covered by the browser checks

page.html's 400 identical lines do not produce the cluster shape that triggers the inflation, so a check added there detected only the 9px floor and was dropped. The limitation is recorded in the harness README instead; the oracle is a real document served to a real webkit.