Judge the SHEET too, and correct a line-count figure the proxy flattered

[tannevaled]

Two measurements this repository could not make, and one published number a sharper instrument contradicts. Findings written to /Users/Shared/xfa-measure/FINDINGS.md as they came, with the scripts, the instrumented copies and the pdfium patch beside them.

Lead with what was invisible

Ten sheets are opened on the wrong page area, and nothing here could count them. us-uscis__g-1055 6, i-956g 3, i-956 1 — the three forms #21 and #23 left open. The sheet's SIZE cannot see it: 528 of the 559 forms give every page area of a form the same medium, so choosing the wrong one leaves the size right.

doc.go's "same line count as pdfium 82.5%" was not a line count. It was (our h − pdfium h) / OUR line height, bucketed, and the proxy flatters. Counting lines with pdfium's own count in hand gives 76.3%, and 1 002 leaves the proxy scored as agreeing take a different number of lines. fw9's Page4.Col2.F, quoted in #23 as a success, is one: four lines of 9 pt here against pdfium's three of 12 — 36 pt either way.

And v0.18.0's "7 sheets whose size disagrees with pdfium" is 0. Its script compares float tuples for equality and counts FORMS; all seven are ties at the fourth decimal — 1008.0 against 1008.0001. The real content of that table row is its next line, 6 orientation errors before the fix and 0 after.

The controls, before any number

• the instrumented copy of the package is byte-identical to the plain one on all 560 forms;
• the plain build reproduces v0.19.0's shipped dumps byte for byte, and reproduces its published line-count table exactly (7 358 leaves, 82.5% / 12.5% / 4.1% / 0.8%) before it is disputed;
• the rebuilt pdfium probe's geometry is byte-identical to the dumps every release since Settle t657 against pdfium, stop turning the sheet for a hidden container's break, and place the last 24 #18 was judged against, and the README's three sheet counts are unchanged: i-956 17, i-956g 24, g-1055 96;
• Place is byte-identical to a real v0.18.0 build on all 560 forms, so the "no fonts" column is v0.18.0's;
• this change moves no layout: all 560 forms byte-identical before and after.

Gap 1 — TestSheetsAgainstPdfium

3035 sheets lined up by index
the same SIZE          3035/3035  100.00%   largest disagreement 0.0000 pt
the same PAGE AREA     3025/3035   99.67%

placer.sheetAreas records it here; the probe reads it from GetPage(i)'s form node there, so it is known even on the 91 sheets of g-1055 whose page area draws no furniture. Neither side reads it off the geometry being judged.

Gap 2 — pdfium's own line count

text-lines-trace.patch.py, in the probe directory beside the other two, emits per leaf pdfium measured: its line count and one height per line. lineHeights is read where it lies; nothing is called that was not called already.

over 6 960 leaves	no fonts	with fonts
same number of lines	23.2%	76.3%
one more	35.2%	20.2%
two or more	41.5%	2.4%
FEWER	0.1%	1.1%

Where they came from, against the old bands:

band	same n	a WRAP	no count
<0.5	4717	1002	355
0.5–1.0	392	487	39
1.0–1.5	160	141	3
≥1.5	40	21	1

The band #23 named was genuinely mixed, near enough half and half. The worse news is the bucket above it.

Where the counts agree, the whole residue is the FIRST line — 5 372 of 5 373 — and our line height for every line after it is pdfium's to a hundredth of a point on 1 177 of 1 178. pdfium makes the first line the font size (CXFA_TextParser::GetLineHeight, bFirst); pdf.js makes it the face's line height less its gap, 1.1172 ems for Arial, and this follows pdf.js. The gap is 0.1172 × size — 1.172 pt at ten points, 0.938 at eight — which is the measured median and quartile exactly. A disagreement with pdfium, not a defect against the reference, and nothing is changed for it.

The 20% extra wraps are not pdfium's break tolerance. pdfium lets a line overrun by a fifth of the font size before breaking (SetLineBreakTolerance(fFontSize * 0.2f)). Turning the same rule on in an instrumented copy moves the agreement 76.3% → 77.2%. Hypothesis tested and rejected.

What I could NOT settle

• 89 sheets on 9 forms are lined up against nothing, the two sides disagreeing on how many sheets there are. Three of those nine are the three page-area forms.
• Why we take one more line on 1 571 draws. Spread over 205 forms, 983 of them where pdfium fits one line. Not the tolerance, and not concentrated.
• The 10 leaves still off the paper and g-1055's unpaired one are untouched.
• My own page-area record would misalign if a sheet were dropped. dropEmptyPages removes sheets; the version committed here keeps sheetAreas in step with it, and no corpus form drops one (560 of 560 record exactly as many sheets as they ship), so the out-of-repository script that did not was not wrong here.
• pdfium measured text for 16 FIELDS in 560 forms. Every other field writes its own height, so the line-count measure is a measure of draws. That is the corpus, not the instrument.

Gate: gofmt clean, go vet clean, exact 100% statement coverage with XFACORPUS unset, -race, 13 cross-compile targets, CGO_ENABLED=0, GOWORK=off, Go 1.27.1 via GOTOOLCHAIN.

🤖 Generated with Claude Code