A written height is a ceiling, and the judge can see 592 more boxes

[tannevaled]

What this is

Two changes that came out of diagnosing the nine remaining sheet-count
disagreements with pdfium (#7). Neither changes a sheet count; both were
measured before being shipped.

1 — The judge could not see 592 boxes

somPath cut pdfium's SOM expression at every .. pdfium escapes a dot that
is part of a NAME — ArtifactedHeader[0].A\.Original[0] — so splitting on all
of them left a backslash in the rewritten path, the key matched nothing this
package emits, and the box was paired with nothing. 35 of the 559 dumped forms
name an element that way.

The rates were never wrong, both sides being unpaired, but they were blind.

against pdfium	before	after
keys this package emits and pdfium does not	790	260
leaves pdfium emits and it does not	33462	32932
under a table row, paired	19522	19590
under neither — the control, paired	167651	168085
of those, agreeing on x	163772	164206

Every one of the 502 newly paired boxes agrees with pdfium on x. Had the
rewrite paired the wrong pairs, they would not.

2 — A container's written height is a ceiling, not a floor

measure returned max(content+marginV, own), following pdf.js
(template.js:5222). pdfium reads it the other way round:
CalculateContainerSpecifiedSize (cxfa_contentlayoutprocessor.cpp:97-137)
turns bContainerHeightAutoSize off as soon as a subform writes an h above
kXFALayoutPrecision, and CalculateContainerComponentSizeFromContentSize
(:140-184) then leaves componentSize.height at that written height, never
reading fContentCalculatedHeight at all.

ca-cra__rc243-fill-26e is the case in the small. <subform name="Detail2" h="4.233mm"> holds children reaching 8.466mm. Both sides agree to the point on
the row above it, which ends at 595.0970 + 11.9991 = 607.0961, and that is
where pdfium puts Detail2 — the written 11.9991 tall, not the 24.9991 its
content reaches.

Followed: pdfium, by the standard that decided px, mp, =0mm, the
root's absent layout and the hidden container's break.

against pdfium, y	before	after
under a wrapping container	427/959 — 44.53%	527/959 — 54.95%
under a table row	15044/19590 — 76.79%	15437/19590 — 78.80%
under neither — the control	158206/168085 — 94.12%	158209/168085 — 94.12%

x: not one box moved, at any of the three. w: not one box moved. Sheets
3090 → 3090, unplaced 48 → 48, fields 85455 and draws 156010 both unchanged.
Of 559 forms 0 are worse and 13 better, 8 of them becoming exact on sheet
AND y for every leaf.

The cost, and it is a real one. Against pdf.js, container heights
7794/7794 (100.00%) → 7762/7794 (99.59%). Those 32 are exactly the
containers pdf.js grows past their written h. This is a decision BETWEEN the
two references, not a regression against a settled answer.

A height written as NOUGHT stays no height, as pdfium reads one only above
kXFALayoutPrecision. No container of the 560-form corpus writes one, so that
arm is a guard rather than a measured claim, and the new test pins it.

Gate

Go 1.27.1 via GOTOOLCHAIN, GOWORK=off, CGO_ENABLED=0: gofmt -l empty,
go vet clean, 100.0% of statements, -race green, and ten cross-compile
targets (linux/amd64, linux/arm64, linux/386, darwin/amd64, darwin/arm64,
windows/amd64, windows/arm64, freebsd/amd64, js/wasm, wasip1/wasm).

The diagnosis this came out of — what the nine are, grouped by cause, and what
I could not settle — is posted on #7.

🤖 Generated with Claude Code