From 68840bed0c6db3a3d294e020cb43cd4b66ab0afb Mon Sep 17 00:00:00 2001 From: Robert Allan James Date: Tue, 11 Aug 2026 20:20:59 -0400 Subject: [PATCH] FABRIC.md: item 4.4o -- 640x480 scroll-box centering math computed Pure geometry, no code change. Blocking question checked first: both 4.4n CANVAS heights (688px amd64, 488px aarch64/riscv64) clear the 480px minimum, so no architecture fails the fit. amd64: box raster top-left (320,104), 320px side margins, 104px top/bottom margins. aarch64/riscv64: box raster top-left (80,4), 80px side margins, 4px top/bottom margins (confirms 4.4n's 16px gap choice lands exactly where predicted). Also translated both into TTF-TEXT's Cartesian bottom-left-origin convention for whatever later item issues the actual TTF-TEXT calls: amd64 bottom-left (320,216), aarch64/riscv64 bottom-left (80,116). Co-Authored-By: Claude Sonnet 5 --- FABRIC.md | 30 +++++++++++++++++++++++++++++- 1 file changed, 29 insertions(+), 1 deletion(-) diff --git a/FABRIC.md b/FABRIC.md index fae583b..2276562 100644 --- a/FABRIC.md +++ b/FABRIC.md @@ -5522,7 +5522,7 @@ document and committing that amendment as its own item.* > preserve. Any larger gap than 4.4m's ceiling would have failed this; recorded as > confirmation the earlier warning held, not a new finding. -- [ ] **4.4o — 640×480 scroll-box centering math within CANVAS.** Layout math computed on top +- [x] **4.4o — 640×480 scroll-box centering math within CANVAS.** Layout math computed on top of `TTF-TEXT`'s own coordinate primitive, which is simpler and already fixed: Cartesian, origin at the bottom-left of the **physical framebuffer** (not CANVAS-relative — resolved and implemented ahead of this item, 2026-08-11, `ttf_words.c`'s `baseline_y = fb_height() - @@ -5535,6 +5535,34 @@ document and committing that amendment as its own item.* and reports which architecture's CANVAS is too small. *Refs:* §27.8. + > **Done 2026-08-11.** Pure geometry, no code change. **Blocking question checked first, not + > assumed clear:** both 4.4n CANVAS heights (688px amd64, 488px aarch64/riscv64) are ≥ 480px + > — no architecture fails the fit, so this proceeds to centering math rather than stopping to + > report a failure. + > + > Centered within 4.4n's CANVAS rect (itself top-left (0,0) on both architecture classes, so + > centering within CANVAS is centering within the screen minus the strip): margin + > = `(canvas_dim − box_dim) / 2` per axis, symmetric by construction. + > + > **amd64 CANVAS 1280×688:** `x = (1280−640)/2 = 320`, `y = (688−480)/2 = 104` (raster, + > top-down — matches this item's own "top-left" phrasing and how `fb_fill_rect()` already + > addresses pixels). Box spans raster x:[320,960], y:[104,584] — 320px side margins, 104px + > top/bottom margins, both symmetric. + > + > **aarch64/riscv64 CANVAS 800×488:** `x = (800−640)/2 = 80`, `y = (488−480)/2 = 4`. Box + > spans raster x:[80,720], y:[4,484] — 80px side margins, the full 4px top/bottom margin + > 4.4n's 16px-gap choice was picked to leave (8px total split 4px/4px top/bottom, confirming + > that margin lands exactly where 4.4n predicted, not a new finding). + > + > **Translated into TTF-TEXT's Cartesian, bottom-left-origin convention** (`y_cartesian = + > fb_height − y_raster`, `ttf_words.c`'s own flip), for whatever later item actually issues + > `TTF-TEXT` calls to draw within the box — reference corner is the box's bottom-left, matching + > that origin: + > - amd64: box bottom (raster) = 104+480 = 584 → `y_cartesian = 800−584 = 216`. **Bottom-left + > (320, 216).** + > - aarch64/riscv64: box bottom (raster) = 4+480 = 484 → `y_cartesian = 600−484 = 116`. + > **Bottom-left (80, 116).** + - [ ] **4.4p — Three-arch screendump verification of 4.4l–4.4o.** Geometry only — not the toggle or scrollback. *Done when:* screendump on all three architectures shows the 640×480 box centered within