Skip to content

Report PDF: ADR-034 horizontal-overflow rule (max(horizontalRatio) <= 1) is documented but unenforced #2003

Description

@steilerDev

[product-architect]

Context

ADR-034 (Client-Side-Report-PDF-Generation) minimum-bar rule #1 states:

No horizontal overflow: max(node.positions[].horizontalRatio) <= 1. horizontalRatio is (x - pageMargins.left) / innerWidth (DocumentContext.js:490), so a value above 1 means laid-out content advanced past the printable right edge. This is the only assertion that actually proves "nothing ran off the page".

That rule is not implemented. grep -rn "horizontalRatio" client/ returns zero hits.

The rule was corrected into ADR-034 during the #1914 documentation pass (it previously stated the wrong table._minWidth <= printableWidth() form, which both false-negatives and false-positives — see ADR-034's Deviation Log entry for 2026-08-04). The corrected assertion was documented but never landed as a test, so the ADR currently sets a bar that nothing enforces.

Why this matters now

Every horizontal-overflow fix in this pipeline is therefore verified by mechanism rather than outcome — tests assert that wordBreak: 'break-all' is present on the right run, not that the rendered content stayed inside the printable width. That is a proxy: it confirms the intended code path was taken, but it cannot catch a case where the mechanism fires and the content still overflows (e.g. a token whose safeTokenChars threshold was computed against the wrong column width, or a future column-width edit that invalidates a threshold silently).

Two recent PRs are in exactly this position:

Note the interaction with rule #2 (height bound): the dontBreakRows silent-drop defect means an over-tall row is discarded with no throw and no warning, so neither overflow direction fails loudly on its own. Render-derived assertions are the only detection channel for either.

Important

Amended 2026-08-05 by product-owner — the max(horizontalRatio) <= 1 form quoted above is SUPERSEDED.
Implementing this issue proved the documented bar itself unmeasurable for this pipeline: horizontalRatio
is recorded at the left edge of each text line and before the line is placed
(ElementWriter.js:32), so for the overview table — all-fixed widths summing exactly to
printableWidth() — it is structurally 0 for every input. Mutation testing in the PR #2008 review
confirmed removing wordBreak: 'break-all' left a <= 1 assertion green.

ADR-034 rule #1 was corrected accordingly (3rd correction, Deviation Log 2026-08-05): the content-extent
check is now per-cell _minWidth <= widths[i]._calcWidth after a real render, and maxHorizontalRatio
is re-scoped as the narrower table-box positioning check. Read the Context quote and Proposed-work item 2
below as historical. Acceptance bullets 1-3 are unchanged and were satisfied in that corrected form —
see PR #2008 and
the round-2 review.

Proposed work

  1. Add a reusable helper in the reportPdf test layer that walks a rendered pdfmake document's node tree and returns max(node.positions[].horizontalRatio) (verify against DocumentContext.js:490 for the pdfmake version currently pinned — the field is internal and version-sensitive, which is why it belongs behind one helper rather than inlined per test).
  2. Assert <= 1 [SUPERSEDED 2026-08-05 — assert per-cell _minWidth <= _calcWidth; see the amendment above] in realRender.test.ts across the existing worst-case fixtures, for both en and de — ADR-034 finding B2 established that German is consistently the binding locale for width bugs in this table, so a single-locale assertion would be the weaker check.
  3. Include the over-wide-token fixtures from fix(reports): route usage-cell grey meta suffix through per-token runs #2002 ('W'.repeat(30) in areaText, and the equivalent in usageText) as first cases.
  4. Consider pairing it with rule EPIC-02: Application Shell & Infrastructure #2's tableOffsetsTotal(cols) + sum(widths[i]._calcWidth) <= printableWidth() table-box assertion, which is likewise documented and likewise unimplemented.

Acceptance

  • A render-derived horizontal-overflow assertion exists and is exercised by the worst-case Usage/Vendor/header fixtures in both locales.
  • The assertion demonstrably fails when a safeTokenChars threshold or a column width is deliberately broken (revert test — a passing new assertion that cannot fail is the specific failure mode to avoid here; see ADR-034's history of assertions that passed on nothing).
  • ADR-034 rule EPIC-01: Authentication & User Management #1 gains a pointer to the implementing test so the documented bar and its enforcement stay linked.

Notes

Pre-existing debt — not introduced by #2002, and explicitly recorded as non-blocking in that PR's round-2 review. Filed as the follow-up I committed to owning there.

Metadata

Metadata

Assignees

No one assigned

    Projects

    Status
    Done

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions