The preferred CJK shape of a character varies from region to region. Here’s some examples of the preferred shape of the same codepoint for Taiwan, China PRC and Japan respectively:
Let’s say a CN region glyph is used for users of TW and JP. Some differences are subtle (e.g. 系), but for碌 and 鷂, their differences are large enough for native users to feel unnatural.
Android uses the user defined language preference order in System Settings to choose the appropriate region variant.
Starting from Android 5.0, Droid Sans Fallback is replaced by Noto Sans CJK to provide region-specific glyphs of different CJK regions. The fallback chain can be found here. The system tries to use the font which lang tag matches the user’s language preference, and ultimately falls back to NotoSansSC-Regular.otf if the glyph couldn't be found in the language-specific font file (in this setup, only NotoSansSC-Regular.otf contains the full glyph set, while others contain only the glyphs which shapes are different from it).
From Android 7.0, the system is updated so that region-specific glyph font is achieved by selecting a different ttcIndex in a single ttc file. So no more fallback and the logic is much simpler.
It looks like Flutter isn’t respecting such preference in its view. Here’s a comparison of how the characters look like in Flutter rendered widget (center) and TextView in native activity started in the same Flutter app using Method Channel (right):
As you see, CN glyphs are always used in Flutter rendered widgets. Not only the system preference hasn't been taken into account, it also seems that we the developer can do nothing to override this behavior (unless we use our custom CJK font, which isn't a viable option most of the time given the size of such a typeface). I've tried explicitly defining the locale in MaterialApp but no luck.
I currently have no access to an iOS device so I can't comment on it.
Doctor summary (to see all details, run flutter doctor -v):
[√] Flutter (Channel beta, v0.2.8, on Microsoft Windows [Version 10.0.16299.371], locale zh-HK)
[√] Android toolchain - develop for Android devices (Android SDK 27.0.1)
[!] Android Studio (version 3.0)
X Unable to determine bundled Java version.
[√] Android Studio (version 3.1)
[!] Android Studio (version 2.1)
X Unable to find bundled Java version.
[!] VS Code, 64-bit edition (version 1.19.1)
[√] Connected devices (1 available)
The preferred CJK shape of a character varies from region to region. Here’s some examples of the preferred shape of the same codepoint for Taiwan, China PRC and Japan respectively:
Let’s say a CN region glyph is used for users of TW and JP. Some differences are subtle (e.g. 系), but for碌 and 鷂, their differences are large enough for native users to feel unnatural.
Android uses the user defined language preference order in System Settings to choose the appropriate region variant.
Starting from Android 5.0, Droid Sans Fallback is replaced by Noto Sans CJK to provide region-specific glyphs of different CJK regions. The fallback chain can be found here. The system tries to use the font which
langtag matches the user’s language preference, and ultimately falls back toNotoSansSC-Regular.otfif the glyph couldn't be found in the language-specific font file (in this setup, onlyNotoSansSC-Regular.otfcontains the full glyph set, while others contain only the glyphs which shapes are different from it).From Android 7.0, the system is updated so that region-specific glyph font is achieved by selecting a different
ttcIndexin a single ttc file. So no more fallback and the logic is much simpler.It looks like Flutter isn’t respecting such preference in its view. Here’s a comparison of how the characters look like in Flutter rendered widget (center) and TextView in native activity started in the same Flutter app using Method Channel (right):
As you see, CN glyphs are always used in Flutter rendered widgets. Not only the system preference hasn't been taken into account, it also seems that we the developer can do nothing to override this behavior (unless we use our custom CJK font, which isn't a viable option most of the time given the size of such a typeface). I've tried explicitly defining the
localeinMaterialAppbut no luck.I currently have no access to an iOS device so I can't comment on it.