You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Aug 8, 2023. It is now read-only.
Repository navigation
This repository was archived by the owner on Aug 8, 2023. It is now read-only.
After #10522 and #10662, we hard-code the PingFang font and suggest its use — this will fail on iOS 8, because it wasn’t introduced until iOS 9 (alongside the SF system font).
For Chinese system fonts on iOS, Heiti SC/TC were the predecessors to PingFang SC/TC/HK.
Happy to change the example in the comments to whatever we think is best, but I'm not sure Heiti is obviously better? In the case iOS can't load what you requested, it has font fallback behavior (full disclosure: I don't know how the fallback behavior works, I've just seen it while testing). So for instance I tried changing the "PingFang" test to the definitely-not-installed-on-my-system "HurgleBurgle" and it still renders a reasonable-looking result:
There's no place other than that unit test where "PingFang" is hard coded.
I set breakpoints inside the core classes to spot-check the data flowing thru while working on the ObjC wrapper and saw iOS decide to use Helvetica when a bogus or non-existent font was specified. It could be worth doing this again for iOS 8 if we're worried about it, but I suspect it might just work ™
iOS does implement font fallback. I also wondered in #10522 (comment) whether PingFang also fell back to SF Text on newer systems, because the PostScript font names are actually PingFangHK, PingFangSC, and PingFangTC, not simply PingFang.
Hrm, so it sounds like it would be useful to better understand and then document the fallback behavior. This all makes me wonder if not specifying any font and allowing the system to choose wouldn’t produce a better result on iOS.
For instance, if the developer specifies PingFang and we use it to render the entire CJK range, but the user is looking at Japanese text, this would result in a worse visual experience (because iOS has the Hiragino fonts for Japanese and PingFang does a poor job with non-Chinese characters).
To @1ec5’s point, this is also a concern with simply PingFang — is it rendering Simplified, Traditional, or Hong Kong Chinese glyphs? I’m deeply unfamiliar with the Chinese unicode range(s), but it would be good to (re-)confirm that we’re showing the correct characters with the best typeface in each situation. This article indicates that some characters share the same code point but should be rendered differently at the font-level.
Activity
ChrisLoer commentedon Dec 12, 2017
Happy to change the example in the comments to whatever we think is best, but I'm not sure Heiti is obviously better? In the case iOS can't load what you requested, it has font fallback behavior (full disclosure: I don't know how the fallback behavior works, I've just seen it while testing). So for instance I tried changing the "PingFang" test to the definitely-not-installed-on-my-system "HurgleBurgle" and it still renders a reasonable-looking result:
There's no place other than that unit test where "PingFang" is hard coded.
/cc @1ec5
akitchen commentedon Dec 12, 2017
I set breakpoints inside the core classes to spot-check the data flowing thru while working on the ObjC wrapper and saw iOS decide to use Helvetica when a bogus or non-existent font was specified. It could be worth doing this again for iOS 8 if we're worried about it, but I suspect it might just work ™
1ec5 commentedon Dec 12, 2017
iOS does implement font fallback. I also wondered in #10522 (comment) whether
PingFangalso fell back to SF Text on newer systems, because the PostScript font names are actuallyPingFangHK,PingFangSC, andPingFangTC, not simplyPingFang.friedbunny commentedon Dec 12, 2017
Hrm, so it sounds like it would be useful to better understand and then document the fallback behavior. This all makes me wonder if not specifying any font and allowing the system to choose wouldn’t produce a better result on iOS.
For instance, if the developer specifies
PingFangand we use it to render the entire CJK range, but the user is looking at Japanese text, this would result in a worse visual experience (because iOS has the Hiragino fonts for Japanese and PingFang does a poor job with non-Chinese characters).To @1ec5’s point, this is also a concern with simply
PingFang— is it rendering Simplified, Traditional, or Hong Kong Chinese glyphs? I’m deeply unfamiliar with the Chinese unicode range(s), but it would be good to (re-)confirm that we’re showing the correct characters with the best typeface in each situation. This article indicates that some characters share the same code point but should be rendered differently at the font-level.akitchen commentedon Dec 14, 2017
Where would be the most appropriate place to document this? In the Info.plist key documentation?
friedbunny commentedon Dec 15, 2017
@akitchen Yeah, I suppose that’d be the only place iOS developers would end up seeing it.
[ios, macos] Updates documentation to describe font fallback on iOS 8
[ios, macos] Updates documentation with default CJK font recommendations
[ios, macos] Updates documentation with default CJK font recommendations
[ios, macos] Updates documentation with default CJK font recommendations
[ios, macos] Updates documentation with default CJK font recommendations
[ios, macos] Updates documentation with default CJK font recommendations