Settle t657 against pdfium, stop turning the sheet for a hidden container's break, and place the last 24

[tannevaled]

What I could not settle

Why pdfium's own pagination is what it is for the twenty subforms it piles up. I settled that it does it and why the form makes it do it — the mechanism is three lines of pdfium quoted below — but I ran no controlled pdfium experiment. The dump was read, not re-produced under a variant, so the causal chain rests on pdfium's source and on the geometry agreeing with it, not on a subject I moved.

Where a hidden container's leaves belong. pdfium places them at the cursor, off the paper if that is where the cursor is, and us-irs__f4797's six agree with it to the point. Whether that is right — as against reporting them unplaced — is not something either reference settles, and this changes nothing about it.

The remaining nine sheet-count disagreements with pdfium are untouched and undiagnosed. us-uscis__g-1055 (64 against 96) is the loudest of them now.

t657: not a layout disagreement at all

Ours 27, pdf.js 27, pdfium 7 — and two references agreeing settled nothing. What settled it was that the body leaf sets are identical: 2 300 (kind, path) pairs each side, diff empty, and every one agrees on x to the point. The only count difference is 20 extra copies of the page area's own furniture field, one per extra sheet.

So it is neither a repeat count nor a fit. form1 is layout="tb" with 27 page-sized children, each exactly the content area. pdfium's sheets:

sheet	what is on it	y
0–3	Page1…Page4	18
4	QuerySheet	18
4	Sub2015a…Sub2024b — all twenty	774
5, 6	Page26, Page27	18

774 is the bottom edge of the content area. The 1 701 leaves under those twenty are at exactly our y + 756.0, every one, reaching y=1530 on a 792-point sheet.

Every one of those twenty, and no other top-level subform, carries an initialize script that writes form1.Sub20NNx.presence = "hidden". Page1…Page4, QuerySheet, Page26 and Page27 have zero .presence assignments anywhere in the template. pdfium is built with pdf_enable_v8 and runs them; hidden then does three things:

• PresenceRequiresSpace() is true only for visible and invisible (cxfa_node.cpp:5348-5353);
• ProcessBreakBeforeOrAfter returns std::nullopt when the break's container does not require space (cxfa_viewlayoutprocessor.cpp:922-928), so nineteen <breakBefore targetType="pageArea" startNew="1"/> never create a page;
• the forced page end is gated the same way (cxfa_contentlayoutprocessor.cpp:1922-1927), so a cursor already past the bottom does not end the sheet either.

Cursor never advances, breaks never fire. 7 is right for the document as its scripts leave it; 27 is right for the document with scripts unrun, which is what this package and pdf.js lay out. Nothing to change in the placer for t657.

The control the corpus handed back: one form, no scripts needed

Censused: exactly one container in 560 templates writes presence="hidden" and carries a live break. us-irs__f4797, three page-sized subforms under a tb root, the third presence="hidden" with <breakBefore targetType="pageArea" startNew="1"/>. pdfium: 2 sheets. This package: 3. pdf.js: cannot lay the form out at all, so pdfium alone.

Followed: pdfium, by the standard that decided px, mp, =0mm, the per-run occur bound and the root's absent layout. It is also the other half of a rule this package already kept — a hidden container is given no room by the flow above it, and a container that takes no room has no reason to turn the page.

After: 2 sheets, and all six leaves under the hidden subform agree with pdfium on x AND y to the point — 810.5301, 810.0000, 821.9990, 858.4554, 857.9991, 882.0000 on an 11-inch sheet.

Corner anchors: 24 of 24, and the number is 72 → 48

Not a new capability after all. heightOf already computes exactly pdfium's number — its positioned arm is max(y + h) over the children and measure adds the margin, which is DoLayoutPositionedContainer's fContentCalculatedHeight (cxfa_contentlayoutprocessor.cpp:1192-1204) handed to CalculateContainerComponentSizeFromContentSize (:543-560). It was never asked for at the anchor.

	before	after
unplaced over 560 forms	72	48
anchored by a corner	24	0
page area never used	48	48
fields placed	85 446	85 455
draws placed	155 995	156 010
sheets	3 091	3 090

All 24 are ca-cra__t183-fill-25e's <subform name="Part_A" anchorType="bottomLeft" y="55.034mm"> with no w, no h. Children reach 22.225mm = 63pt; 55.034mm = 156pt; 156 − 63 = 93, plus the content area's 18 = 111. pdfium puts Part_A_Heading at 111.0019. So does this — and so do the other 23, on sheet, x, y, w and h, to the last place a float carries.

Width is still refused. Only an anchor along the middle or the right edge moves a box by its width, no container of the corpus is one, and nothing here computes a container's content width.

The judge, re-audited because the population moved

24 boxes entered it. The pdfium control goes 167 632 → 167 651 paired and 163 753 → 163 772 agreeing: +19 and +19, reconciling exactly.

The other five pair only by hand. pdfium spells them Part_A[0].SIN_Line4[1]…[1], indexing a name that also occurs deeper in the same subtree, which somPath's rewrite does not reproduce. The judge drops such keys rather than mis-pairing them, so the agreement rate was never wrong — only blind to those five. Checked by hand: all five agree with pdfium to float precision.

Every judge still passes: pdf.js placement 176/176 exact, container heights 7 794/7 794, pagination 151 309 boxes all on the same sheet across 476 forms, pdfium x under a table row 19 522/19 522 and under a wrapping container 959/959.

Gate

100% of statements, go vet, gofmt -l empty, -race, nine cross-compile targets — all under Go 1.27.1 via GOTOOLCHAIN, CGO_ENABLED=0, GOWORK=off.

🤖 Generated with Claude Code