source-han-code-jp VS source-han-sans

M+ Code and Source Han Code JP

Early computers were mainly used for programming — well, you couldn’t really switch fonts in the terminal on the fly, could you? Maybe you could, and it’s certainly baked in these days, but it was more expedient to just incorporate European characters (a few hundred glyphs at most) onto an existing CJK font (several thousand glyphs). This was already in the days of cold type, so manipulation (stretching, compressing, tilting) was within easy reach, which resulted in the fonts looking like the way they do. Yes, those fonts trace their lineage back to the 1970s and early 1980s. The Latin characters are monospaced essentially due to technical limitations, at roughly 2:1 (half the width of a CJK character). Japan also made half-width kana simply to accommodate this, and this is also where fullwidth forms, now an essential part of the vaporwave aesthetic, came from. More recently, Adobe made a variant of Source Han Mono JP just to have non-CJK characters be in a 3:2 ratio.

Moreover, I see a roughly 50/50 split of the glyph standard in traditional Chinese texts; it is not uncommon for "Jiu Zixing" and Taiwan MOE styles to appear on the same page. The HK version (middle) is a recent addition per the "Splitting TWHK into TW & HK" issue on GitHub. I have never seen any print text following the HK standard, though you may see them occasionally in online media due to preinstalled HK fonts such as PingFang or Noto Sans.

Babelstone Han or [Source Han Sans](https://github.com/adobe-fonts/source-han-sans} are probably your best bets? Couldn't find any other typefaces that might cover obscure characters like these

Try Source Han fonts (https://github.com/adobe-fonts/source-han-sans or https://github.com/adobe-fonts/source-han-serif) from Google/Adobe. It's the default font on Android and should display it wonderfully: 𰻝 (simplified) or 𰻞 (traditional).

I believe Windows's approach is localisation not globalisation. Many programmes runs properly only in designed locales, not that programmes run well in any locale.

Chinese/Korean rendered incorrectly on English UI because system hardcoded a font fallback, which put Japanese font first, regardless of how languages are ordered in the Settings. This is largely true for traditional Win32 programmes, like Chrome, Edge, Explorer.exe, etc. However UWP apps using the new UI framework (like Unigram, Intel Command Centre etc) behave correctly if setting Chinese/Korean as secondary language.

It's different on macOS or iOS however, if you set a system locale order as 1. English, 2. Chinese, then Chinese content will render correctly with correct Chinese system font PingFang.

Another issue that is also very important is that Chinese (Simplified or Traditional), Korean and Japanese share amount of the same characters but written differently. That means system must render the glyph in correct variant, like in the example of Source Han Sans

https://github.com/adobe-fonts/source-han-sans/raw/release/S...

According to people from adobe its even a JIS standard to make those two kanji narrower