opentype.js VS source-han-sans

[3] https://github.com/opentypejs/opentype.js

With an SVG we can define our image as code, which is pretty neat. But SVG is not able to wrap texts. We can use opentype.js to calculate the width of our texts and to wrap it manually. Finally we have to convert the SVG to a PNG, because the most of social media platforms do not support SVG. This approach could work, but requires a lot of code and it is very complicated.

The repo is public so you can take a look if you're curious. I used opentype.js to convert the font into SVG in real-time. It was a PITA.

Still a few bugs to work out but I learned a ton making this! One of the cool things I learned is that you can read a font file, convert it to a base 64 string, slap it in a style element, and show that font in the browser! Huge thanks to opentype.js as well!

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