Repository navigation
[Bug] Latin/ASCII characters render as corrupted glyphs when mixed with Chinese text #3570
Description
Bug Description
Latin characters (English letters, punctuation, numbers) are rendering as severely corrupted, unreadable glyphs when displayed alongside Chinese (CJK) characters in the UI. Chinese characters themselves render correctly, but all ASCII content appears broken — showing distorted, overlapping symbol fragments instead of legible text.
This appears to be a font fallback or glyph rendering issue, likely triggered when the system attempts to render mixed CJK + Latin content using an incompatible or missing font.
Steps to Reproduce
Open the application in an environment where the system locale or primary font is set to a CJK language (e.g., Simplified Chinese).
Navigate to any panel or view that displays mixed Chinese and English/ASCII text (e.g., terminal output, dialog components, task lists).
Observe that Latin characters and numbers are rendered as garbled, corrupted symbols while Chinese characters display normally.
Expected Behavior
All characters — both Chinese (CJK) and Latin/ASCII — should render clearly and legibly using appropriate font fallback chains.
Actual Behavior
Latin/ASCII characters are displayed as distorted, overlapping glyph fragments (see screenshot). Chinese characters are unaffected.
Screenshots
Activity
github-actions commentedon Apr 19, 2026
Triage notes: I investigated this but could not write a reproduction test that is meaningful in
bun:test.Why a unit test isn't feasible
The bug is a visual/browser-level rendering failure that depends on runtime conditions we can't simulate in a Node/Bun test environment:
apps/desktop/src/renderer/lib/terminal/terminal-addons.ts:46whereWebglAddonis loaded.None of these are exercisable with
document/canvasstubs.Likely affected code
apps/desktop/src/renderer/lib/terminal/appearance/index.ts:42—DEFAULT_TERMINAL_FONT_FAMILIESlists Latin-only monospace fonts (JetBrains Mono, Menlo, Monaco, etc.) followed by the genericmonospace. When the OSmonospacegeneric resolves to a CJK font (common on systems with a CJK primary font), the terminal cell metrics and the fallback glyph metrics diverge, which in turn corrupts the WebGL atlas.apps/web/src/app/globals.css:7-8andapps/marketing/src/app/globals.css:5-6— the global--font-family-sans/--font-family-monostacks have no explicit CJK-capable fallback either, so the same class of issue can surface in dialogs / lists whenever the OS generic resolves to a CJK font.Suggested direction (not applied here)
A proper fix likely requires either (a) adding explicit CJK-capable monospace fallbacks (e.g. "Noto Sans Mono CJK SC", "Source Han Mono SC") after the Latin fonts, or (b) using
@font-facewithunicode-rangeto scope Latin glyphs to a known-good monospace font so fallback only kicks in for CJK codepoints. Validating either would need hands-on testing in an Electron build with a CJK-locale OS and the matching screenshot repro.Happy to revisit if someone can capture the value of
xterm.options.fontFamily/ computedfont-familyon the broken machine, plus the OS and the resolvedmonospacegeneric there.Cnotech commentedon Apr 21, 2026
Got that too after upgrading to 1.5.6, both Claude Code and Codex
atlas555 commentedon Apr 22, 2026
after upgrade
atlas555 commentedon Apr 23, 2026
not only chinese , but also english !
Need bugfix quickly, can not work !
allenxln commentedon Apr 26, 2026
+1
allenxln commentedon Apr 26, 2026
Chiming in with repro data and two workarounds that narrow this down significantly. cc @Kitenite
Environment
navigator.platform = MacIntelnavigator.language = zh-CN, system localezh-CNdocument.fonts.check()returnstruefor all of: PingFang SC, SimSun, Microsoft YaHei, Noto Sans Mono CJK SC, Source Han Mono SC, Menlo, JetBrains Mono. So this is not a "missing CJK font" problem on my machine.Two workarounds that make the garbling instantly disappear (both very reliable, tested just now):
Both trigger an xterm
resize→ WebGL texture atlas rebuild. This strongly suggests the corrupted state is the initial atlas, not the underlying character stream or the installed fonts. Content stays correct after recovery until the app is restarted.One data point that looks suspicious
With the terminal in the garbled state, I ran:
and got:
No monospace family at all. But
terminal.options.fontFamilyatapps/desktop/src/renderer/lib/terminal/terminal-runtime.ts:109is set from the monospace stack inappearance/index.ts:42. So the element's computed CSSfont-familyand the xterm renderer'sfontFamilyoption appear to diverge at startup on my machine — I'm not sure if xterm's internal char-measure element is affected too, but if cell metrics end up measured against a proportional stack while glyphs are rasterized from a monospace one, atlas corruption would be the expected outcome, and a resize would "fix" it by re-measuring.I haven't been able to pinpoint the CSS source of this divergence from the repo alone — could be a stylesheet load-order race, a Tailwind
@layerspecificity collision, or something else. Happy to dig further if useful.Possibly relevant
Let me know if there's anything else useful to capture (e.g. a particular timing snapshot,
terminal.optionsdump, devtools trace on first paint). I can put together a draft PR if a direction is confirmed — but wanted to share the data first in case the CSS divergence above points somewhere obvious to someone who knows the render pipeline.allenxln commentedon Apr 26, 2026
Quick follow-up: I traced the CSS path in the repo and the divergence is, I think, explainable from source alone.
@xterm/xterm@6.0.0/css/xterm.cssdoesn't setfont-familyon.xtermitself — only on.xterm-accessibility-tree..xtermrule inapps/desktop/src/renderer/globals.css:177-184only setsheight/width..xterminherits frombody, which picks up Tailwind v4 preflight's default sans-serif stack — exactly what my earliergetComputedStyleoutput showed.Filed as #3758 (Draft) — a one-line CSS addition. Details and reasoning in the PR description. Marking it Draft because I haven't set up a local desktop build yet; on a change this small and this CSS-local that felt like the honest state to leave it in. Happy to take direction from there.
Kitenite commentedon Jul 11, 2026
Closing as a duplicate of #5605, the consolidated tracker for stale
terminal-renderingissues from the July 2026 stale-issue sweep (no activity since 2026-06-01). If this still applies on a current build, comment on #5605 and we'll reopen.