Repository navigation
OHOS: Also push HarmonyOS Sans SC & HarmonyOS Sans TC as candidate fallback fonts when special characters are encountered. - #47116
Conversation
HarmonyOS Sans SC & TC as candidate fallback fonts when special characters are encountered. HarmonyOS Sans SC & HarmonyOS Sans TC as candidate fallback fonts when special characters are encountered.
90e9a03 to
e6a9af9
Compare
e6a9af9 to
f29563e
Compare
There was a problem hiding this comment.
This seems too broad:
https://docs.rs/unicode-script/latest/unicode_script/enum.Script.html#variant.Common
| Script::from(options.character) == Script::Common | ||
| { |
There was a problem hiding this comment.
This seems too broad. But I don't know how this system works.
There was a problem hiding this comment.
From wikipedia,
However, many characters—those that are not part of a formal natural-language writing system or are unified across many writing systems—may be used in more than one script (for example, currency signs, symbols, numerals, and punctuation marks). In these cases Unicode defines them as belonging to the "common" script (ISO 15924 code "Zyyy").
I think this is what we want? After all, brackets & fullstops exist in more than one language
There was a problem hiding this comment.
I think this is what we want?
I don't think we want to change Latin punctuation.
I think we should do Unicode block match right below.
UnicodeBlock::CJKSymbolsandPunctuation
There was a problem hiding this comment.
hmm, I'm not aware of this before. let me check it out
edit: oh ok; this one is more specific
Signed-off-by: Richard Tjokroutomo <richard.tjokro2@gmail.com>
f29563e to
387e717
Compare
|
@jschwe Does this look ok? |
|
Hmm, I guess we can go ahead with this for now. There will be more cases like this though, where we are missing the fallback characters. |
Follow up from [servo#47116](servo#47116), now more CJK blocks are covered by `HarmonyOS Sans SC` & `HarmonyOS Sans TC`. Testing: Manual testing. Signed-off-by: Richard Tjokroutomo <richard.tjokro2@gmail.com>
Yep. After some testing on different test sites, I noticed we hit the fallback path way too often; so up next we can fix the font matching procedure. |
…e fallback fonts when special characters are encountered. (servo#47116) Currently, `fallback_font_families()` only push `HarmonyOS Sans SC` & `HarmonyOS Sans TC` when a character is a Chinese character (e.g. `你`, `我`, etc.). However, there are also Chinese special characters such as Chinese brackets ( `【】`). These special characters are not considered as Han scripts by `unicode_script`. As a result, these special characters won't be rendered on OHOS devices. Therefore, we need to also consider `HarmonyOS Sans SC` & `HarmonyOS Sans TC` if we encounter special characters. Testing: Manual testing. Signed-off-by: Richard Tjokroutomo <richard.tjokro2@gmail.com>
Follow up from [servo#47116](servo#47116), now more CJK blocks are covered by `HarmonyOS Sans SC` & `HarmonyOS Sans TC`. Testing: Manual testing. Signed-off-by: Richard Tjokroutomo <richard.tjokro2@gmail.com>
Follow up from [servo#47116](servo#47116), now more CJK blocks are covered by `HarmonyOS Sans SC` & `HarmonyOS Sans TC`. Testing: Manual testing. Signed-off-by: Richard Tjokroutomo <richard.tjokro2@gmail.com>
Currently,
fallback_font_families()only pushHarmonyOS Sans SC&HarmonyOS Sans TCwhen a character is a Chinese character (e.g.你,我, etc.). However, there are also Chinese special characters such as Chinese brackets (【】). These special characters are not considered as Han scripts byunicode_script. As a result, these special characters won't be rendered on OHOS devices.Therefore, we need to also consider
HarmonyOS Sans SC&HarmonyOS Sans TCif we encounter special characters.Testing: Manual testing.