# Do the three engines agree on text geometry?

Partly, and the part they disagree on is sharply localized. Every other corpus this
project checks the engine against is text-free by construction
(`crates/harness/src/cases.rs`'s module doc) and the held-out WPT filter
(`oracle/suites/normal-flow-pages.mjs`) rejects any page with a text node, so until now
nothing had measured whether Chromium, Firefox and WebKit place glyphs closely enough for
the geometry vote (`docs/geometry-verification.md`) to run at all. This is that
measurement. It builds no layout code.

**The short answer.** Line breaking and element geometry are votable; the text fragment
rect is not. All three engines broke every line at the same place in both fonts, and the
element boxes of a text-bearing page agree at 1/60 px 99–100% of the time. But the rect a
text node's own line fragment occupies disagrees systematically: Firefox makes it 1 px
taller than the other two almost always, and in the proportional font the three engines
never once agreed on a line's width. Loosening the tolerance does not rescue it — the
differences are whole-pixel-scale, not sub-pixel.

```mermaid
flowchart TD
  probe["textProbe:<br/>pinned font, 3 engines"] --> lines{"same number<br/>of line fragments?"}
  lines -- "yes, 100% of the time<br/>in both fonts" --> boxes{"element boxes<br/>within 1/60 px?"}
  boxes -- "yes, 99-100%" --> ok["element geometry of a<br/>text-bearing page: votable"]
  boxes --> frag{"text fragment rect<br/>within 1/60 px?"}
  frag -- "x: yes in Ahem, 81.7% in Lato<br/>width: 96.6% in Ahem, 0% in Lato" --> horiz["horizontal: font-dependent"]
  frag -- "y and height: 4-9%" --> vert["vertical: no, in either font"]
```

## What was measured

- **Probe**: `docs/dump-format.md` → "Text probe". One request renders a document with a
  pinned font embedded as a `data:` URL and returns, per engine, the ordinary element dump
  plus every text node's `Range.getClientRects()` — one rect per line fragment. An engine
  whose page fell back to a system font fails the request rather than being measured, so
  no figure here is contaminated by font substitution.
- **Cases**: `crates/harness/src/text_cases.rs`, ten categories (`TextCategory::ALL`), each
  run in both fonts with byte-identical markup. The run below is `enumerated()` plus 60
  seeded-random cases at seed `0x7e47`, so 70 cases per font.
- **Quantities**: each element's bounding box and per-fragment rects, voted by
  `crates/harness/src/compare.rs` `vote()`; each text node's fragment count and per-fragment
  x, y, width and height, voted by `crates/harness/src/trace.rs` `vote_text()`. Both use
  `Consensus` at `dump::TOLERANCE_PX` = 1/60 px.
- **Binary**: `crates/harness/src/bin/text_metrics.rs`. Raw responses are kept under
  `corpus/text-metrics/<font>/<case>.json` (gitignored) so a rerun on other engine versions
  can be diffed against this one.

A text node that produced no line box in any engine — the contents of every `<style>`,
including the injected `@font-face` rule — is reported by the probe but dropped from these
tallies rather than counted as agreement about geometry that does not exist.

### Engines

From Playwright, launched with the oracle's `default` profile on Linux:

| Engine | Version |
|---|---|
| Chromium | 153.0.8010.12 |
| Firefox | 155.0 |
| WebKit | 26.6 |

Every number below is valid only for these builds. The vote's tolerance, 1/60 px, is the
coarsest grid any of them rounds to (Firefox's app units); Chromium and WebKit use 1/64.

### Fonts

Both are files in the WPT checkout `oracle/suites/suites.json` pins (commit
`26f417a8c0`), whose sparse list already fetches `/fonts/`.

| Key | File | Version | License | sha256 |
|---|---|---|---|---|
| `ahem` | `fonts/Ahem.ttf` | 1.50 | Public domain, with a Creative Commons fallback for jurisdictions that do not recognize it (stated in the font's own name table; `http://dev.w3.org/CSS/fonts/ahem/COPYING`) | `b719ecb31c5b21fc573c03f6421c74ac63c271a5a3ff841e34f9705fb94b8448` |
| `lato` | `fonts/Lato-Medium.ttf` | 2.015 | SIL Open Font License 1.1, © 2011–2015 tyPoland Lukasz Dziedzic, reserved font name "Lato" (stated in the font's own name table) | `be8bbf7105500e8fc1f9429307fb396905a0e6cff63fe1eb751bb319d0f1b0db` |

Ahem's every glyph is a 1 em square and it is the font WPT's own text-bearing layout tests
use, so it is the case most likely to agree. Lato is proportional, with real advances,
kerning pairs and hinting; it was chosen over the other proportional faces in that
directory because it is a TrueType file rather than a WOFF, so the ordinary hinting path is
exercised, and because it states its own license, which is where the license above was read
from rather than assumed.

## Ahem

3581 measurements over 70 cases. 91.6% unanimous, 8.0% 2-1, 0.4% split.

| Category | Voted | Unanimous | 2-1 | Split | Max delta px |
|---|---|---|---|---|---|
| one word, integer font size | 322 | 95.7% | 4.3% | 0.0% | 1.000000 |
| one word, fractional font size | 230 | 95.2% | 4.3% | 0.4% | 7.500458 |
| wrapping at a fixed width | 534 | 85.4% | 14.6% | 0.0% | 1.000000 |
| `line-height` in px | 540 | 88.9% | 8.3% | 2.8% | 1.000000 |
| `line-height` as a number | 270 | 88.9% | 11.1% | 0.0% | 1.000000 |
| `white-space: pre` | 276 | 97.1% | 2.9% | 0.0% | 1.000000 |
| `<span>` inside a line | 315 | 85.7% | 14.3% | 0.0% | 1.000000 |
| `letter-spacing` | 414 | 95.7% | 4.3% | 0.0% | 1.000000 |
| kerning pair | 238 | 97.5% | 2.5% | 0.0% | 1.000000 |
| `text-align: center` | 442 | 92.8% | 7.2% | 0.0% | 1.000000 |
| **all** | **3581** | **91.6%** | **8.0%** | **0.4%** | **7.500458** |

The per-category view is misleading on its own: the disagreement is not spread across
categories, it is one quantity appearing in all of them. Grouped by what was measured
rather than by which case measured it:

| Quantity | Voted | Unanimous | 2-1 | Split | Max delta px | Outlier |
|---|---|---|---|---|---|---|
| element x | 495 | 100.0% | 0.0% | 0.0% | 0.000748 | — |
| element y | 495 | 99.0% | 1.0% | 0.0% | 0.500000 | firefox ×5 |
| element width | 495 | 100.0% | 0.0% | 0.0% | 0.000641 | — |
| element height | 495 | 99.0% | 1.0% | 0.0% | 1.000000 | firefox ×5 |
| element fragment count | 495 | 100.0% | 0.0% | 0.0% | 0.000000 | — |
| element fragment width | 215 | 100.0% | 0.0% | 0.0% | 0.000641 | — |
| element fragment height | 215 | 97.7% | 2.3% | 0.0% | 1.000000 | firefox ×5 |
| text fragment count | 80 | 100.0% | 0.0% | 0.0% | 0.000000 | — |
| text fragment x | 149 | 100.0% | 0.0% | 0.0% | 0.001389 | — |
| **text fragment y** | 149 | **4.0%** | 85.9% | 10.1% | 0.875000 | firefox ×124, chromium ×4 |
| text fragment width | 149 | 96.6% | 2.7% | 0.7% | 7.500458 | chromium ×4 |
| **text fragment height** | 149 | **6.7%** | 93.3% | 0.0% | 1.000000 | firefox ×139 |

**Firefox reports the text fragment one pixel taller, and half a pixel higher, than the
other two.** One word at 16px, the simplest case in the corpus:

| Engine | fragment y | fragment height | fragment width |
|---|---|---|---|
| Chromium | 0.0 | 16.0 | 240.0 |
| Firefox | −0.5 | 17.0 | 240.0 |
| WebKit | 0.0 | 16.0 | 240.00045776367188 |

The widths agree to 0.00046 px, well inside the tolerance. The height does not, and it is
the same 1 px in essentially every case — which is why `text fragment height` is unanimous
only 6.7% of the time while every horizontal quantity is unanimous 96.6% or better.

**The 7.5 px outlier is Chromium rounding glyph advances to whole pixels at a fractional
font size.** "Hamburgefonstiv" (15 glyphs) at `font-size: 13.5px`:

| Engine | fragment width | per glyph |
|---|---|---|
| Chromium | 210.0 | 14.0 |
| Firefox | 202.5 | 13.5 |
| WebKit | 202.49954223632812 | 13.499969… |

Firefox and WebKit keep the fractional em advance; Chromium rounds it up to the next whole
pixel and the error multiplies by the glyph count. This is the only place in Ahem where a
horizontal quantity leaves the tolerance, and it needs a font size that is not a whole
pixel — the same precondition `docs/firefox-app-units.md` found for the box-geometry
divergence, with a different engine as the outlier.

## Lato

3401 measurements over 70 cases. 90.1% unanimous, 7.7% 2-1, 2.2% split.

| Category | Voted | Unanimous | 2-1 | Split | Max delta px |
|---|---|---|---|---|---|
| one word, integer font size | 322 | 93.5% | 6.2% | 0.3% | 1.000000 |
| one word, fractional font size | 230 | 94.3% | 1.7% | 3.9% | 4.949997 |
| wrapping at a fixed width | 450 | 88.0% | 10.0% | 2.0% | 2.185547 |
| `line-height` in px | 500 | 88.0% | 8.0% | 4.0% | 1.000000 |
| `line-height` as a number | 250 | 88.0% | 10.0% | 2.0% | 1.000000 |
| `white-space: pre` | 276 | 94.9% | 2.9% | 2.2% | 1.000000 |
| `<span>` inside a line | 315 | 78.7% | 18.1% | 3.2% | 1.812607 |
| `letter-spacing` | 414 | 93.5% | 6.5% | 0.0% | 1.000000 |
| kerning pair | 230 | 93.5% | 4.3% | 2.2% | 3.793808 |
| `text-align: center` | 414 | 91.3% | 6.5% | 2.2% | 1.000000 |
| **all** | **3401** | **90.1%** | **7.7%** | **2.2%** | **4.949997** |

| Quantity | Voted | Unanimous | 2-1 | Split | Max delta px | Outlier |
|---|---|---|---|---|---|---|
| element x | 495 | 99.0% | 1.0% | 0.0% | 1.812607 | chromium ×5 |
| element y | 495 | 99.4% | 0.6% | 0.0% | 0.500000 | webkit ×3 |
| element width | 495 | 99.0% | 0.6% | 0.4% | 0.400009 | chromium ×3 |
| element height | 495 | 99.4% | 0.6% | 0.0% | 1.000000 | firefox ×3 |
| element fragment count | 495 | 100.0% | 0.0% | 0.0% | 0.000000 | — |
| element fragment width | 215 | 97.7% | 1.4% | 0.9% | 0.400009 | chromium ×3 |
| element fragment height | 215 | 98.6% | 1.4% | 0.0% | 1.000000 | firefox ×3 |
| text fragment count | 80 | 100.0% | 0.0% | 0.0% | 0.000000 | — |
| text fragment x | 104 | 81.7% | 14.4% | 3.8% | 1.812607 | chromium ×15 |
| **text fragment y** | 104 | **8.7%** | 77.9% | 13.5% | 0.750000 | webkit ×77, firefox ×4 |
| **text fragment width** | 104 | **0.0%** | 50.0% | 50.0% | 4.949997 | chromium ×52 |
| **text fragment height** | 104 | **8.7%** | 91.3% | 0.0% | 1.000000 | firefox ×95 |

**The three engines never once agreed on a line's width in Lato.** Not one of the 104
measurements was unanimous; half were 2-1 with Chromium named, and the other half were
three-way splits with no reference value at all. The kerning case at 16px shows all three
mechanisms at once:

| Engine | fragment width | fragment y | fragment height |
|---|---|---|---|
| Chromium | 157.0 | −2.0 | 19.0 |
| Firefox | 159.51666259765625 | −2.0 | 20.0 |
| WebKit | 160.52565002441406 | −1.5 | 19.0 |

Chromium's whole-pixel rounding of the run width, seen in Ahem only at fractional font
sizes, applies to *every* line in a proportional font, because a proportional advance is
essentially never a whole pixel. That alone would leave a 2-1 vote with Chromium as the
standing outlier. But Firefox and WebKit are 1.01 px apart from each other as well — they
do not apply this font's kerning identically — so the measurement is a three-way split half
the time.

`<span>` inside a line is the worst category (78.7% unanimous) for the same reason: the
span's position depends on the width of the text before it, so a width difference becomes a
position difference for everything after it on the line.

## Loosening the tolerance does not help

A measurement is unanimous at tolerance *T* exactly when the spread between the extreme
engines is at most *T*, so one pass over the stored spreads answers the question for every
*T* at once:

| Tolerance | Ahem | Lato |
|---|---|---|
| 1/60 px (the vote) | 89.95% | 88.08% |
| 0.125 px | 89.95% | 88.39% |
| 0.25 px | 89.95% | 89.84% |
| 0.5 px | 94.28% | 93.98% |
| 1 px | 99.87% | 98.62% |
| 2 px | 99.87% | 99.43% |
| 4 px | 99.87% | 99.86% |
| 8 px | 100.00% | 100.00% |

Going from 1/60 px to 0.25 px — fifteen times looser — buys nothing in Ahem and 1.8 points
in Lato, because the disagreements are not sub-pixel. Reaching 99% needs a 1 px tolerance,
sixty times the vote's, at which point the vote can no longer distinguish a correct box
from one that is a whole pixel wrong; that is not a tolerance, it is giving up on geometry
verification. Full agreement needs 8 px in both fonts.

## Verdict

**Ahem: yes at 1/60 px, with Firefox a standing named outlier on the fragment's vertical
extent.** The vote's own bar is not unanimity — `compare::vote` accepts a 2-1 majority and
takes the pair's value as the reference, skipping only a full split. By that bar 99.6% of
Ahem measurements carry a trustworthy reference. A text-bearing generated function can be
scored against a three-engine vote in Ahem, provided two things are understood: the
reference for `text fragment y` and `text fragment height` will come from a Chromium–WebKit
pair with Firefox outvoted about 90% of the time, which is a much weaker guarantee than the
unanimity element geometry enjoys; and fractional font sizes must be avoided or Chromium
becomes an outlier on width too.

**Lato: no.** Half of all `text fragment width` measurements are three-way splits, so half
of the horizontal geometry of a line has no reference value at any tolerance the vote could
adopt. The other half yields only a Firefox–WebKit pair, and those two are themselves over
a pixel apart on kerned text. A generated function whose output is a line's width, a
glyph's advance, or the position of anything after text on a line cannot be scored against
this vote in a proportional font. Element geometry of the same pages remains votable at
99%+, so a function that consumes text only as an opaque inline box still can be.

**What both fonts agree on, and it matters:** line breaking. `text fragment count` and
`element fragment count` were unanimous in 100% of measurements in both fonts, across the
wrapping, `white-space: pre`, `letter-spacing` and `text-align: center` categories — the
engines never once disagreed about how many lines a text node broke into or where the
breaks fell. Where a line *starts* and how *tall* it is are contested; *whether* it starts
is not.

### What this blocks

Against `docs/platform-areas.md` → "Text and internationalization" → "Text rendering (font
loading and fallback, shaping, line breaking and hyphenation, glyph rasterization)":

- **Blocked in a proportional font**: shaping and glyph advances. The measured quantity —
  the advance width of a run of Latin text — has no three-engine reference value half the
  time, so a generated shaping or advance-measurement function cannot be scored against this
  vote. This is the number, not a softening of it: 0 of 104 measurements unanimous.
- **Blocked in both fonts**: the vertical extent of a line box as `Range.getClientRects()`
  reports it. Firefox differs by a whole pixel from Chromium and WebKit in over 90% of
  measurements, in Ahem as much as in Lato.
- **Not blocked**: line breaking. It is the one part of that row this vote can carry today,
  in both fonts, at 1/60 px.
- **Not blocked**: the element geometry of pages that contain text. A text-bearing document
  does not degrade the box-geometry vote — 99–100% unanimous, maximum difference 0.0007 px
  on element width in Ahem. The text-free corpora were a simplification, not a necessity, as
  far as element boxes are concerned.

An oracle that could score shaping would have to be something other than a three-engine
geometry vote — the engines do not agree, so there is nothing for a vote to find.

## Reproducing

```
cargo run --release -p harness --bin text_metrics -- --random 60 --seed 0x7e47
```

It needs the pinned WPT checkout; `node oracle/suites/fetch.mjs wpt` fetches it if the
fonts are missing, and the probe says so by name rather than measuring something else.
`node oracle/selftest.mjs --engines=chromium,firefox,webkit` checks the probe end to end,
including that the pinned Ahem really loaded — two of its glyphs at 100px are exactly 200px
wide, which no substituted font would produce.