Repository navigation
Question: desktop-readability width budget vs preferred text floor — intended headroom at 1440×900? #618
Description
Question
composition/desktop-readability (v3) caps the complete viewBox width at 1240px on the legacy-930 budget basis (930px available diagram width at 1440×900).
Arithmetic at the cap: scale = 930/1240 = 0.75 →
- 8px supporting text projects to 6.0px — exactly the failure floor, zero headroom
- 9px preferred sublabel text (per authoring-defaults) projects to 6.75px — below the ~7.5px guidance for ordinary context text
A field team measuring delivered artifacts reports the effective projected-text ceiling at ~8.25px (their number, not yet reproduced on my side), i.e. below the 9px preferred floor, which makes a class of dense-but-legitimate legacy diagrams unfixable except by content removal.
Ask
- Is the 1240px cap intended to be viewport-adaptive (e.g. wider allowed when targeting 1920+ displays), or deliberately fixed at the 1440 baseline?
- If fixed, is the intended answer for dense legacy diagrams 'split/compact content' (current authoring-contract guidance) — or is a documented relaxed/ratchet profile planned for grandfathered diagrams?
Context: a production atlas of 143 diagrams measured 35 v3-blockers and 38 both-fail, most of them desktop-readability on hand-placed 1250–1390px canvases. We compacted the daily-gated ones successfully; the question is whether the long tail needs a policy knob or just elbow grease.
Filed on behalf of the atlas-engine field deployment (archify 3.0.1).
Activity
ThinkDonk commentedon Sep 30, 2026
Same family, real project numbers, useful for calibrating whether the 1440 baseline stays fixed.
My diagram is a 3-lane 8-node swimlane sourced from a ~260k loc C# warehouse backend. At the 930px budget the only window that passed both gates was viewBox width roughly 825 to 1023. The delivered artifact is 1000x534: a 6.6px sublabel source projects to 6.14px, so 0.14px of headroom against the 6px floor. When I tried 1440x660 (the ratio fix described in #616) it failed at 4.26px projected, exactly as your arithmetic predicts.
One side effect worth noting: I had to shorten sublabels (transDistribution to transDist) not to fit the box but to keep the projected font above the floor. So for our case the vertical-overflow fix and the readability cap fight each other at the 1440 baseline, and the working resolution was deleting content rather than picking a profile.
tt-a1i commentedon Sep 30, 2026
Thanks for the examples. The current width budget, viewport baseline, and text thresholds are open to revision if changing them produces better diagrams. Feel free to explore an implementation rather than treating those numbers as fixed constraints.
The main requirement is to preserve or improve generated diagram quality: readable text, complete content, clear hierarchy, and a layout without clipping or collisions. Please watch for regressions in ordinary diagrams as well as improvements in dense ones. Passing a relaxed check alone would not demonstrate an improvement.
Please include before/after examples and real-browser comparisons at representative screen sizes, so we can judge the actual results. If there are tradeoffs, we can discuss them as they arise. If the improvement is clear and verification supports it, I'm happy to move toward merging it. #631 can be explored alongside this; there is no need to settle the exact configuration interface before trying an approach.
testikun commentedon Oct 27, 2026
I'd like to take a focused current-dev readability verification slice, following the request for complete-content examples and real-browser evidence.
I'll compare ordinary and dense/wide public fixtures at 1440x900 and a wider viewport, recording actual diagram width, projected text sizes, clipping and scrolling alongside the static readability diagnostics. The aim is to distinguish the legacy width-budget assumptions in this report from current Reader behavior, and identify any remaining gap without deleting content to make checks pass.
The first deliverable will be a reproducible measurement report and a recommendation based on the results. This is not another typography-scale implementation or a replacement for #649 / #1104; any proposed change to thresholds or authoring fields would need its own scope discussion. The work will be AI-assisted, with synthetic/public evidence kept distinct from the reporter's private atlas.