Cut a positioned container where its author permits it, and place 182 more leaves

[tannevaled]

Closes nothing; it is one slice of #7.

pdf.js refuses to split a container at layout === "position" before it
reads keep.intact, so <keep intact="none"/> — the author's explicit "you may
break this" — is unreachable in it. This package followed pdf.js and put 1 423
body leaves off the paper across 39 forms where pdfium put 25 across 6.

The rule is narrower than #7's diagnosis said, and that is the first finding

FindSplitPos calls FindLayoutItemSplitPos
(cxfa_contentlayoutprocessor.cpp:503-588), which switches on
CXFA_Node::GetIntact():

None                   recurse into the children; the cut may stand
ContentArea/PageArea   *fProposedSplitPos = fCurVerticalOffset  — walk UP
default                return false — no change

and GetIntact (cxfa_node.cpp:1536-1591) answers ContentArea for a subform
whose layout is position or row — so the proposed cut is driven to nought,
FindSplitPos returns nought, and InsertFlowedItem's
if (fSplitPos > kXFALayoutPrecision) is false: the container moves whole —
unless a <keep> is written, where GetIntactFromKeep returns what the
author wrote.

So pdfium does not cut positioned containers in general. It cuts one exactly
where <keep intact="none"/> is written on it. #7's previous comment read the
exemption off bCalculateMargin = eLayout != Position, which governs the margin
arithmetic and not the gate.

The population is 58 positioned subforms across 17 of the corpus's 560 forms
— not the 39 whose off-paper leaves the position clause dominates. Recorded
before measuring anything, so the measurement is not read against the wrong
expectation.

The mechanism

pdfium's split is a post-hoc slice of an already-laid-out item tree, so
cuttable is a different question from splittable and answered by a different
function. The container is never put on the flowing chain: it is laid out
whole and then cut, and each part's children keep the y the template wrote for
them, less however much of the container is on the sheets before —
SplitLayoutItem's pChildItem->s_pos_.y -= fSplitPos. Letting the flow split
it would have placed every child by the cursor instead, which is the design
constraint #7 named.

One difference, deliberate: pdfium recurses into a child whose intact is none
— a field of a positioned container is one — and, finding nothing finer, cuts
it in half, emitting two layout items for the one node. A Box is one
rectangle for one occurrence and Layout promises every body leaf appears
exactly once, so the cut is refused there and the container moves whole,
which is also what pdfium does when FindSplitPos comes back at nought.

Measured, against pdfium over 559 forms

	before	after
paired body leaves	177676	177676
ambiguous keys dropped	9157	9157
agree on x	173806 (97.82%)	173806 (97.82%)
agree on sheet+y	162018 (91.19%)	162200 (91.29%)
forms perfect on x	465/559	465/559
forms perfect on sheet+y	403/559	403/559

Exactly two forms move and no form is worse on either measure:

us-uscis__i-956    42 -> 168  of 491
us-uscis__i-956g  118 -> 174  of 538

The judge's pairing was re-audited, because this moves boxes onto sheets they
were not on: the population is identical, 177676 paired and 9157 dropped before
and after. Nothing became ambiguous — that is what the bisect refusal buys.

i-956's page-area sequence goes from Page2 ×2, Page3 ×10 to
Page2 ×13, Page3 — pdfium's shape is Page2 ×16, Page3 — which repairs the
regression #20 recorded rather than tuned away. Sheets: corpus 3086 → 3088,
i-956 12 → 14 (pdfium 17). Off the paper: 1423 → 1378 boxes across 39 → 37
forms.

The cut positions are pdfium's, to four decimals

An instrumented build over all 560 forms attempts the cut five times on four
containers, all on i-956 and i-956g. i-956's sfPart2:

behind=0.0000     room=162.1843  at=162.1843    5 children
behind=162.1843   room=648.0000  at=744.1824   19 children
behind=744.1824                  rest           1 child

pdfium's own trace: splitPos=162.1843, then 581.9981 from 162.1843, and three
items of 162.1843 + 581.9981 + 222.0010. Independent arithmetic, the same two
numbers, the same partition of the 25 children. The second is sfP2_Line13's
written y, reached because GetIntact() answers ContentArea for a positioned
subform with no keep.

What it does not do, and what it costs

• Two of the five attempts are refused because the cut would bisect a field:
  i-956's sfPart7_2 and i-956g's sfCertification. Both still move whole.
• Of the 58 permitted containers, 54 never fail to fit, so the permission is
  never exercised on them. The rule is real, correct and rare.
• +182 of 15 658 sheet+y disagreements is 1.2%, against a bucket labelled
  42.1%. The label was a correlation over whole forms; the reason it could not be
  the prediction is above, and was written down before the measurement.
• An exclGroup and a row carrying the permission would be cut by pdfium too; the
  corpus writes neither, so nothing would say whether it were right.

Gate: 100% statement coverage including every error branch, go vet, gofmt -l
empty against Go 1.27.1 via GOTOOLCHAIN, -race, thirteen cross-compile
targets, CGO_ENABLED=0, GOWORK=off.

🤖 Generated with Claude Code