Glyph fonts: renderable trim indicators, and vertical metrics on IGlyphFont

[mstrobel]

A FIGlet-trimmed line could render its trim indicator as nothing at all — no bundled face has a glyph for U+2026, and the formatter budgeted for an ellipsis the face could not draw. Fixing that exposed a second defect underneath it.

Renderable trim indicators

IGlyphFont.HasGlyph(uint) is a default interface member, so external implementors stay source-compatible. ShadowedFont and DecoratedFont forward to Inner — inheriting the optimistic default would silently reinstate the bug behind any decorator.

TextFormatter picks the indicator per face: the configured Ellipsis if the face can draw it, else "...", else the ellipsis re-sourced to GlyphSource.Default so the terminal's own font draws it. A mismatched indicator is a defect in taste; an invisible one is a defect in correctness.

U+2026 art is authored for eight bundled faces. miniwi and phm-leds ship a truncated required block whose positional layout an appended codetag would corrupt, so they use the derived form, guarded by two table-integrity tests.

Vertical metrics — the defect the fallback created

Runs align to the band's Bottom row, so a one-cell indicator beside a multi-row face landed in the descender row — one row low on standard/small/mini/slant, two on big. Invisible until now because a band whose runs share one face shares their metrics; the mixed-source fallback is the first construct that doesn't.

IGlyphFont gains Baseline, Ascender, Descender, parsed from FLF header field 1.

Baseline is a COUNT of rows from the top through the baseline row — never a 0-based index. The index reading renders correctly on ansi-shadow (7/7) and wrong everywhere else, so contract, remarks and tests all name the distinction, and Baseline_IsARowCount_NotARowIndex pins it against painted ink rather than the header.

VerticalTextAlignment.Baseline is declared last so default stays Bottom; only the last-resort indicator opts in.

The decorators are not pure forwards

	baseline	descent
ShadowedFont	Inner's, unchanged (glyph at the anchor, shadow below)	grows by the offset
DecoratedFont Above	shifts down one	unchanged
DecoratedFont Below	unchanged	deepens by one

All three bundled DecoratedFont instances wrap MonospaceFont, where a single-row inner face makes every reading agree — no shipped configuration could have caught this, so it was derived from the painting code rather than from behaviour.

Two pre-existing quirks were found, documented in <remarks>, and left alone: ShadowedFont with a negative row offset paints outside the box Measure reports, and DecoratedFont draws a Below decoration at a hard-coded row + 1.

Verification

Red-first: the fallback test failed Expected: [4] / Actual: [5] on a 6/5 face — the descender row exactly.

Rendering 689 (+51) · UI 3521 · Drawing 484 · Core 1071 — all green, re-run after rebasing onto develop.

🤖 Generated with Claude Code

https://claude.ai/code/session_01A4i5CZSjkU1TbAgiYBomhL