CJK font rendering regression on macOS 26.5: mixed sans-serif/serif styles within same text

[zayn-0101]

Description\n\nCJK characters are rendered with mixed font styles \u2014 some glyphs appear in a sans-serif style (e.g. PingFang SC / Heiti SC) while others appear in a serif style (e.g. Songti SC) \u2014 within the same text block on macOS 26.5 (Tahoe). This appears to be a regression of the issue fixed in #811 (originally reported in #707).\n\n## Environment\n\n- Ghostty version: 1.3.1 (build 15212, stable)\n- macOS version: 26.5 (25F71)\n- Font engine: CoreText\n- Renderer: Metal (renderer.generic.Renderer)\n- Config: No custom font configured (using default Menlo)\n\n## Steps to reproduce\n\n1. Open Ghostty on macOS 26.5 with default config (no font-family set)\n2. Display any Chinese text, e.g.:\n \n \u8fd9\u6837\u4e24\u4e2a\u5b57\u662f\u9ed1\u4f53\uff0c\u6211\u80fd\u66f4\u7cbe\u662f\u5b8b\u4f53\uff0c\u786e\u662f\u9ed1\u4f53\uff0c\u5730\u5224\u662f\u5b8b\u4f53\uff0c\u65ad\u662f\u9ed1\u4f53\uff0c\u539f\u56e0\u53c8\u6210\u4e86\u5b8b\u4f53\n \n (Translation: each comma-separated clause alternates between "this is sans-serif" and "this is serif" to describe the observed behavior)\n3. Observe that some characters render in sans-serif style (thick, uniform strokes \u2014 like PingFang SC / Heiti SC) while others render in serif style (thin strokes with decorative serifs \u2014 like Songti SC)\n\n## Expected behavior\n\nAll CJK characters should render consistently with the same font style. The system fallback font should be PingFang SC (sans-serif), and all characters should use it uniformly.\n\n## Actual behavior\n\nWithin the same line of pure Chinese text, different characters are rendered with visibly different font styles:\n- Some characters appear in sans-serif style (bold, uniform strokes) \u2014 resembling PingFang SC or Heiti SC (\u9ed1\u4f53)\n- Other characters appear in serif style (light, with decorative strokes) \u2014 resembling Songti SC (\u5b8b\u4f53)\n\nThe pattern is not consistent and varies between terminal sessions.\n\n## Investigation\n\nI performed extensive testing to rule out font resolution issues:\n\n1. CoreText font resolution is 100% consistent: Tested all 20,992 characters in the CJK basic range (U+4E00-U+9FFF) \u2014 every single one resolves to PingFangSC-Regular via CTFontCreateForString. There is zero font fallback at the CoreText level.\n\n2. Terminal.app renders correctly: The same text displays with consistent font rendering in macOS Terminal.app, confirming this is a Ghostty-specific rendering issue.\n\n3. Timeline confirms macOS 26.5 regression:\n - Ghostty 1.3.1 binary installed: 2026-04-29\n - macOS 26.5 installed: 2026-05-15\n - Issue appeared: ~2026-06-02\n - Ghostty binary unchanged during this period\n\n4. Workaround: Using font-codepoint-map to explicitly assign CJK ranges to a specific font (LXGW WenKai Mono, a Chinese-specific monospace font) resolves the issue:\n \n font-codepoint-map = U+4E00-U+9FFF=LXGW WenKai Mono\n font-codepoint-map = U+3400-U+4DBF=LXGW WenKai Mono\n font-codepoint-map = U+F900-U+FAFF=LXGW WenKai Mono\n font-codepoint-map = U+3000-U+303F=LXGW WenKai Mono\n font-codepoint-map = U+FF00-U+FFEF=LXGW WenKai Mono\n \n\n## Root cause hypothesis\n\nmacOS 26.5 appears to have changed the font rendering behavior that the fix in #811 relied on. Since Ghostty's Metal renderer handles its own font fallback logic for CJK characters, changes in macOS's font rendering pipeline can cause the fallback to select different font variants (e.g., different weights or styles within the same font family) for different characters.\n\nThis is consistent with the original issue #707 where Ghostty's fallback was picking a Heavy variant by default, and with the comment from @danielwe on #8712 noting that "Font loading has a lot of state, and sometimes a restart of Ghostty seems to help."\n\n## Related issues\n\n- #707 (original report, fixed in #811)\n- #3365 (same symptom, closed)\n- #8712 (CJK font fallback metrics, closed)\n

[zayn-0101]

This discussion has formatting issues due to a markdown escaping problem. Please see #12919 for the properly formatted version. Closing this one.