You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 736529b
Browse filesBrowse the repository at this point in the historyBrowse files
Repeat position:fixed content on every page, per css-position-3
Verified against the actual W3C spec text (css-position-3): "in paged
media, the page area of each page; fixed positioned boxes are thus
replicated on every page", and UAs "must not paginate the content of
fixed-positioned boxes". Scoped to top/left-anchored fixed content only
(a page header/watermark) - bottom/right are a separate, pre-existing gap:
neither property is parsed for absolute/fixed positioning at all, so a
bottom-anchored footer, the more common real print pattern, needs that
fixed first.
FragmentEmitter now collects every position:fixed box in the tree
(CollectFixedRoots, handling arbitrary nesting depth) and, for each
materialized page, builds a fresh fragment for it against a page-local band
(top=0) rather than the page's real band top - a fixed box's own Location is
already page-relative (CssBox.PerformLayoutImp's Position==Fixed branch
never routes it through normal absolute-Y-computing flow at all), so this
reuses the same geometry unchanged on every page. Excluded from the normal
per-page walk to avoid a duplicate/misplaced render on whichever page its
raw offset would otherwise land on. InlineFragmentation.ApplyLineBreaking
now also skips fixed boxes outright - their content must not paginate.
Confirming this through actual PDF output (not just the fragment tree)
surfaced a second, real, pre-existing bug: FragmentPainter.LiveTreeOffset/
LiveTreeExtraOffset unconditionally undid the current page's band top from
live-tree geometry, on the documented assumption that "band membership is
orthogonal to scroll-offset suppression" for fixed content. That assumption
was true when fixed content only ever appeared on one page (wherever its
raw offset landed) but breaks now that it's intentionally repeated: a fixed
box's live geometry is already page-relative, so subtracting a nonzero band
top pushes its containing-block visibility/overflow-clip check far outside
every page except the one whose band top happens to equal its own small
offset - confirmed via a real generated PDF, where the header only rendered
on page 0. Fixed by making both offsets skip the band-top term entirely for
fixed (or fixed-ancestor) content.
Assert.AreEqual(1,markerHits.Count,$"page {i} should show the fixed marker exactly once - not zero (missing) and not more than one (duplicated by both the repeat mechanism and the normal walk)");
73
+
Assert.AreEqual(5.0,markerHits[0].Top,0.5,$"page {i}'s marker must be at the same page-relative offset (top:5px) as every other page");
0 commit comments