Some Chinese characters displayed as Japanese glyphs on macos

[hans-x]

[hans-x]

直径

[qwerasd205]

These are not explicitly Chinese characters, these are characters in the Unicode CJK Unified ideograph block. What you are observing is the same characters being rendered in different fonts. Whatever font Ghostty is picking as the fallback for these characters happens to use the shinjitai forms of these glyphs rather than the simplified forms. This could maybe be considered a bug depending on if a strange/unexpected font is being picked by the font discovery for the fallback. As a fix that you can apply yourself either way, I believe you can configure your font family to explicitly specify a fallback font that uses the desired forms.

See https://en.wiktionary.org/wiki/%E5%BE%84#Alternative_forms for info on the alternative form(s) situation.

[qwerasd205]

To specify a fallback for your font family configuration, simply include the key a second time, e.g.

font-family = "JetBrains Mono"
font-family = "Hei Regular"

to use JetBrains Mono as your primary font and fall back to Hei Regular (which I believe should have Chinese Simplified forms for CJK Unified Ideograph glyphs) for glyphs not present in JetBrains Mono.

Obviously, you may choose whatever fonts you like best for your main and fallback fonts, the above is just an example.

[mitchellh]

Thanks @qwerasd205.

I agree with that assessment. In the eyes of Ghostty, we're seeing a Unicode codepoint and asking the system what font can satisfy that codepoint. We do this one codepoint at a time, so we're getting it appears a Japanese font first from the system since... codepoints are codepoints.

If you want to ensure that a certain font is used, please do what @qwerasd205 suggested.

If algorithmically you (or anyone!) can suggest something better we can do to improve this, I'd also be happy to hear it!

[hans-x]

20240401-101553.mp4

[mitchellh]

Thanks, let me take a closer look at this. I wonder if there's some locale information or something that we can pass through to the OS APIs to get them to return a different preferred language. The codepoints are just plain old codepoints but maybe there some metadata macOS is giving us that I'm not using yet.

[mitchellh]

Okay, I've had some time to investigate more.

If I configure Japanese IME first (in Settings.app) then Chinese, and never use Japanese input, the characters show up as Japanese characters even from Chinese input. This is in Terminal.app and Alacritty. However, if I configure Chinese first then Japanese IME (again never use Japanese input), the characters show up as Chinese characters. If you try this, you must restart your apps in between.

There seems to be some preferred language order search happening in CoreText that Ghostty is not leveraging. We do our own font sorting that's probably it. I need to do more research.

[mitchellh]

The issue appears to be that we're doing custom fallback search rather than using CTFontForString. CTFontForString returns Chinese as a preference when the locale is English but the issue I have is that our custom search does a better job finding monospace fonts. Still, I'd prefer to match the fallback behavior of other macOS programs by default and as @qwerasd205 pointed out, users can override this...

Looking into it.

[mitchellh]

#1734 This fixes this issue. I compromised by only using CoreText's mechanism for CJK blocks, and our custom font fallback for everything else.