Feature request, not a bug — companion to the horizontal-overflow fix in #81 and to the
existing vertical-overflow warning (#71, "warn when a node overflows past the page bottom").
Summary
When a <Table>'s columns all carry explicit width="..." and their sum exceeds the page's
available body width, the table silently overflows the margin — same failure shape the vertical
case had before #71 added a warning for it. resolve_table_column_widths (touched directly by
#81's fix for the flexible-column case) already has both numbers in hand — total explicit width
and available_width — so detecting this needs no new measurement, just a comparison at the point
#81 already added its explicit-vs-flexible budgeting logic.
Found via
While validating #81, a hand-authored table (12 columns, all explicit widths) summed to 814pt
against a 789.9pt available width on a landscape A4 page. It rendered without any diagnostic,
just a table whose right edge sat exactly on the page's physical edge with no margin at all — the
overflow was only caught by manually measuring pixel margins on the rendered output, not by
anything Docraft said.
Minimal case:
<Document>
<Body margin_left="26" margin_right="26">
<!-- landscape A4 usable width ~= 789.9pt -->
<Table>
<THead><HTitle>A</HTitle><HTitle>B</HTitle><HTitle>C</HTitle></THead>
<TBody>
<Row>
<Cell width="300"><Text>a</Text></Cell>
<Cell width="300"><Text>b</Text></Cell>
<Cell width="300"><Text>c</Text></Cell>
</Row>
</TBody>
</Table>
</Body>
</Document>900pt of explicit column width on a ~790pt budget — renders, exit 0, no warning, table pushed past
the margin.
Suggested behaviour
Mirror the existing vertical warning's wording and severity (warn, don't fail the render — a table
that's a little over is still usually more useful printed than not printed at all):
[WARNING]: A table on page 1 has explicit column widths summing to 900.0pt, wider than the
790.0pt available on the page -- it overflows past the page margin.
Same rationale as #71: this is exactly the kind of authoring mistake (column widths picked without
re-checking the sum against the page) that's easy to make by hand and easy to catch mechanically,
and today it fails silently in a way that's only visible by measuring the rendered PDF.
Feature request, not a bug — companion to the horizontal-overflow fix in #81 and to the
existing vertical-overflow warning (#71, "warn when a node overflows past the page bottom").
Summary
When a
<Table>'s columns all carry explicitwidth="..."and their sum exceeds the page'savailable body width, the table silently overflows the margin — same failure shape the vertical
case had before #71 added a warning for it.
resolve_table_column_widths(touched directly by#81's fix for the flexible-column case) already has both numbers in hand — total explicit width
and
available_width— so detecting this needs no new measurement, just a comparison at the point#81already added its explicit-vs-flexible budgeting logic.Found via
While validating #81, a hand-authored table (12 columns, all explicit widths) summed to 814pt
against a 789.9pt available width on a landscape A4 page. It rendered without any diagnostic,
just a table whose right edge sat exactly on the page's physical edge with no margin at all — the
overflow was only caught by manually measuring pixel margins on the rendered output, not by
anything Docraft said.
Minimal case:
900pt of explicit column width on a ~790pt budget — renders, exit 0, no warning, table pushed past
the margin.
Suggested behaviour
Mirror the existing vertical warning's wording and severity (warn, don't fail the render — a table
that's a little over is still usually more useful printed than not printed at all):
Same rationale as #71: this is exactly the kind of authoring mistake (column widths picked without
re-checking the sum against the page) that's easy to make by hand and easy to catch mechanically,
and today it fails silently in a way that's only visible by measuring the rendered PDF.