The Chinese character 直 is being rendered in the Japanese form, which is why I let Claude Code investigate this:
Environment: Anki main branch (commit 360a2fabc10a804d0fff0307322d0cfc0f16a892), Ubuntu 24.04.4, Qt/QtWebEngine 6.11.0, fonts-noto-cjk 1:20230817+repack1-3.
The bug: Some CJK characters show up with a different shape in Anki than they do in a browser, e.g. 直 (U+76F4). In Firefox it renders as the Chinese form; in Anki’s editor/reviewer, the Japanese-style glyph is shown - even for a field that’s just plain Chinese text, freshly typed, nothing pasted.
A handful of CJK codepoints are shared across Chinese, Japanese, and Korean even though the actual glyph differs by region, so the renderer needs some hint to know which one to draw. stdHtml() in qt/aqt/webview.py builds the webview’s wrapper with a `dir` attribute but no `lang`, and `standard_css()` only sets `font-family: “”, sans-serif` on Linux - nothing that disambiguates.
I assumed adding `lang` would fix it and checked with devtools attached to a running instance (`CSS.getPlatformFontsForNode`, which reports the actual font used to render a node). Turns out `lang` does nothing here. With no `lang`, `lang=“zh-Hans”` or `lang=“ja”` on the element, QtWebEngine picks “Noto Sans CJK JP” every time on my machine. What does work is naming a font explicitly, e.g. `font-family: “Noto Sans CJK SC”`. So it’s controllable, Anki just never tells it which variant to use, and it falls through to whatever fontconfig’s default order happens to be (JP first, on a typical Noto CJK install), regardless of the actual text.
As far as I can tell, there’s no concept of “what language is this note/field in” anywhere in Anki right now, so there’s no clean signal to pick SC vs TC vs JP vs KR automatically. This might be fixable via a preference for one’s preferred CJK variant.