Follow-up to #357 / #361.
PR #361 implements single-page rowspan geometry. It explicitly leaves one case unhandled: a rowspan cell whose span crosses a page boundary.
Problem
In layout/table.go, PlanLayout's row-fit check uses each row's natural gr.height, which now excludes rowspanning cells (their height lives in spanHeight). So the planner believes a spanning row is short, places it near the page bottom, and the draw callback then paints the cell spanHeight tall — bleeding past the page edge with no split. The continuation page also lacks the spanned column entirely.
This does not panic; it is a visual defect on the straddling row only. Single-page tables and tables that paginate between spans render correctly.
Proposed fix
- Make the fit check in
PlanLayout span-aware: when a row contains (or is covered by) a rowspan, treat the whole span as one unit and push it to the next page rather than breaking through it. Repeat the table header on the new page as today.
- Decide behavior when a single span is taller than a full page (must break somewhere) — likely break and clip, or split the span across pages with a redrawn top border.
Example
Add a multipage demo to examples/table-rowspan (a tall schedule grid that forces a span across a page boundary) as part of this fix, so it demonstrates correct pagination rather than the current bug. It was intentionally left out of #361 because it would have shipped the broken render.
Reference
Known-limitation comment: resolveRowspanHeights doc in layout/table.go.
Follow-up to #357 / #361.
PR #361 implements single-page rowspan geometry. It explicitly leaves one case unhandled: a
rowspancell whose span crosses a page boundary.Problem
In
layout/table.go,PlanLayout's row-fit check uses each row's naturalgr.height, which now excludes rowspanning cells (their height lives inspanHeight). So the planner believes a spanning row is short, places it near the page bottom, and the draw callback then paints the cellspanHeighttall — bleeding past the page edge with no split. The continuation page also lacks the spanned column entirely.This does not panic; it is a visual defect on the straddling row only. Single-page tables and tables that paginate between spans render correctly.
Proposed fix
PlanLayoutspan-aware: when a row contains (or is covered by) a rowspan, treat the whole span as one unit and push it to the next page rather than breaking through it. Repeat the table header on the new page as today.Example
Add a multipage demo to
examples/table-rowspan(a tall schedule grid that forces a span across a page boundary) as part of this fix, so it demonstrates correct pagination rather than the current bug. It was intentionally left out of #361 because it would have shipped the broken render.Reference
Known-limitation comment:
resolveRowspanHeightsdoc inlayout/table.go.