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

[zayn-0101]

Description

CJK characters are rendered with mixed font styles — 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) — 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).

Environment

• Ghostty version: 1.3.1 (build 15212, stable)
• macOS version: 26.5 (25F71)
• Font engine: CoreText
• Renderer: Metal (renderer.generic.Renderer)
• Config: No custom font configured (using default Menlo)

Steps to reproduce

1. Open Ghostty on macOS 26.5 with default config (no font-family set)
2. Display any Chinese text, e.g.:

   这样两个字是黑体，我能更精是宋体，确是黑体，地判是宋体，断是黑体，原因又成了宋体
   

   (Translation: each comma-separated clause alternates between "this is sans-serif" and "this is serif" to describe the observed behavior)
3. Observe that some characters render in sans-serif style (thick, uniform strokes — like PingFang SC / Heiti SC) while others render in serif style (thin strokes with decorative serifs — like Songti SC)

Expected behavior

All 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.

Actual behavior

Within the same line of pure Chinese text, different characters are rendered with visibly different font styles:

• Some characters appear in sans-serif style (bold, uniform strokes) — resembling PingFang SC or Heiti SC (黑体)
• Other characters appear in serif style (light, with decorative strokes) — resembling Songti SC (宋体)

The pattern is not consistent and varies between terminal sessions.

Investigation

I performed extensive testing to rule out font resolution issues:

1. CoreText font resolution is 100% consistent: Tested all 20,992 characters in the CJK basic range (U+4E00-U+9FFF) — every single one resolves to PingFangSC-Regular via CTFontCreateForString. There is zero font fallback at the CoreText level.

2. Terminal.app renders correctly: The same text displays with consistent font rendering in macOS Terminal.app, confirming this is a Ghostty-specific rendering issue.

3. Timeline confirms macOS 26.5 regression:

   • Ghostty 1.3.1 binary installed: 2026-04-29
   • macOS 26.5 installed: 2026-05-15
   • Issue appeared: ~2026-06-02
   • Ghostty binary unchanged during this period

4. 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:

   font-codepoint-map = U+4E00-U+9FFF=LXGW WenKai Mono
   font-codepoint-map = U+3400-U+4DBF=LXGW WenKai Mono
   font-codepoint-map = U+F900-U+FAFF=LXGW WenKai Mono
   font-codepoint-map = U+3000-U+303F=LXGW WenKai Mono
   font-codepoint-map = U+FF00-U+FFEF=LXGW WenKai Mono
   

Root cause hypothesis

macOS 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.

This 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."

Related issues

• Inconsistent kanji rendering on macOS #707 (original report, fixed in font/coretext: discovery scoring should take into account symb. traits #811)
• There is a problem with the display of Chinese fonts #3365 (same symptom, closed)
• macOS: CJK font fallback behavior produces overly large metrics estimates #8712 (CJK font fallback metrics, closed)

[danielwe]

Duplicate of #9410? Note the recent insights in #9410 (comment) .