admin/LithosAnanake
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

FABRIC.md: item 4.4n -- CANVAS rectangle computed, per architecture

Browse Source 
Pure geometry, no code change. Gap chosen at 16px, within 4.4m's
flagged <=24px ceiling for the 600px-tall architectures, leaving 8px
of margin rather than cutting to the exact limit.

amd64 (1280x800): CANVAS top-left (0,0), 1280x688, strip at (0,704)
96px tall.
aarch64/riscv64 (800x600): CANVAS top-left (0,0), 800x488, strip at
(0,504) 96px tall.

Checked against 4.4o's 480px scroll-box requirement: 488px clears it
with exactly the 8px margin the gap choice was picked to preserve.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
Robert Allan James
2026-08-11 20:19:21 -04:00
co-authored by Claude Sonnet 5
parent a4afecb656
commit 2b4d426e37
1 changed files with 27 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
FABRIC.md
+27 -1
View File
@@ -5489,13 +5489,39 @@ document and committing that amendment as its own item.*
> flagged here explicitly so it isn't discovered as a surprise failure two items later. amd64
> (800px tall) has no such pressure (`800 − 96 = 704px` for CANVAS + gap).
- [ ] **4.4n — CANVAS rectangle definition, per architecture.** Screen height (4.4l) minus REPL
- [x] **4.4n — CANVAS rectangle definition, per architecture.** Screen height (4.4l) minus REPL
strip height (4.4m) minus the small fixed gap (exact pixel value chosen here) between CANVAS
and the strip.
*Done when:* a CANVAS rectangle (top-left, width, height) is computed and recorded for each
architecture.
*Refs:* §27.8.
> **Done 2026-08-11.** Pure geometry, no code change. Layout follows §27.6's reviewed
> mockup (REPL strip fixed at the bottom of the screen, CANVAS the region above it) and
> uses standard top-down raster coordinates (top-left/width/height) to match this item's own
> phrasing and how `fb_fill_rect()`/`vt100.c` already address pixels — not TTF-TEXT's
> separate bottom-left-origin Cartesian convention, which is a FORTH-word-level API choice
> for its own callers, not a general framebuffer-addressing convention.
>
> **Gap: 16px.** Chosen within 4.4m's flagged `≤24px` ceiling for the small architectures,
> leaving 8px of margin rather than cutting it exactly to the limit; matches the codebase's
> existing small-spacing conventions (`TTF_CACHE_MARGIN`=8, TTF cell leading=4).
>
> **amd64 (1280×800, per 4.4l):**
> - REPL strip: top-left (0, 704), 1280×96
> - Gap: 688–704 (16px)
> - **CANVAS: top-left (0, 0), 1280×688**
>
> **aarch64 / riscv64 (800×600, per 4.4l — identical, same resolution both):**
> - REPL strip: top-left (0, 504), 800×96
> - Gap: 488–504 (16px)
> - **CANVAS: top-left (0, 0), 800×488**
>
> **Checked against 4.4o's 480px requirement, not assumed:** 488px ≥ 480px on the small
> architectures — passes, with exactly the 8px margin the 16px gap choice was picked to
> 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
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