Subj : src/doors/termgfx/font.c font.h src/doors/termgfx/test/test_font.csrc/
To   : Git commit to main/sbbs/master
From : Rob Swindell (on Debian Linux)
Date : Mon Aug 10 2026 21:30:27

https://gitlab.synchro.net/main/sbbs/-/commit/31c8041d2e4fae030806ed8d
Added Files:
	src/doors/termgfx/font.c font.h src/doors/termgfx/test/test_font.c
Modified Files:
	src/doors/termgfx/CMakeLists.txt src/doors/termgfx/test/CMakeLists.txt
Log Message:
termgfx: a bitmap font, so a door can caption its own pixels

Text written to the terminal owns whole character cells. A cell carries a
background colour and there is no "leave what is there" value for it -- not
in cterm, not anywhere -- so a caption over a picture arrives as a rectangle
of background with the caption in it. That is right for a status line on its
own row and wrong for anything meant to float over a game.

Drawing the glyphs as PIXELS sidesteps it: they land in the framebuffer with
everything else, cost no character cells, and take a shadow so they stay
readable crossing from sky to grass mid-word. Indexed rather than RGB,
because a door's framebuffer holds palette indices -- and most termgfx doors
already keep a light and a dark chrome entry, which makes a shadowed glyph
cost no new registers at all.

5x7, uppercase, digits and the punctuation a game label actually uses.
Lowercase folds rather than rendering blank, so a caller need not shout in
its format strings. Five pixels leaves no room for descenders worth having,
and a mixed-case font this small reads worse than clean capitals.

Clipped per pixel: a caption running off the edge loses its tail rather than
the door.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
--- SBBSecho 3.37-Linux
 * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

.