forked from 1b-agent/opencadstudio-upstream
Felix RiestraandClaude Sonnet 5
eb96e8b6ed
Root cause (found by instrumenting build_fallback and reading
ttf-parser's own source, not guessed): cosmic-text's fallback search
picks macOS's system font (San Francisco / SFNS.ttf) for any codepoint
no stroke font or explicitly-requested family covers. It's a variable
TrueType font, and ttf-parser's outline_glyph() resolves a variable
glyph's contours through its gvar table's deltas relative to whatever
variation coordinates are currently set on the Face — an unset Face
has none, so outline_glyph silently returns None (not an error) for
such a glyph. The caller then still returned Some(Glyph { strokes:
vec![], .. }): a "resolved" glyph with nothing to render, no error
anywhere.
Two-part fix:
1. pin_default_variations() sets every variation axis to its own
default value before outlining, applied at all TTF outline-
extraction sites (both build_fallback variants, both build_shaped
variants, and the plain by-family glyph() lookup). This alone
wasn't sufficient for San Francisco specifically — even pinned, its
outline still didn't resolve for the glyphs this bug was found on,
apparently because ttf-parser can't retrieve base glyf data gvar
needs for at least some of that font's accented Latin glyphs.
2. So build_fallback() now treats "resolved a glyph ID but couldn't
extract its outline" as a real failure (outline_from_face returns
None, not an empty glyph) and falls through to a direct fontdb scan
for any other installed font that also covers the character and
can actually be outlined, rather than silently giving up.
Full workspace test suite: 813 passed, 0 failed (previously 812
passed, 1 failed — this was the one pre-existing failure carried
through the entire session).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>