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
Currently the process of loading dynamic fonts for missing graphemes is, we use a list of RegExps to match that character, and use the first match as the final locale. Then, we go to Google Fonts and load that corresponding Noto Sans with that locale.
The problem is that these RegExps are not accurate. It might be not possible at all to generate RegExps for languages (or too large). For example we have Han in both zh-CN, ja-JP, and zh-TW and zh-HK, but this is not always correct. In this example试 is only available in zh-CN but is matched by Han.
We can step back and try to load the actual font instead, and check if that character (unicode) is included in that font. For example to render 试, we matched ["ja-JP", "zh-CN", "zh-TW", "zh-HK"]. And then, we fetch corresponding Google Fonts CSS such as https://fonts.googleapis.com/css2?family=Noto+Sans+JP&display=swap and check their unicode-range to see if 试 is included.
Hi! @shuding I have encountered a minor issue. After successfully
retrieving the necessary font files on the backend server, I am simply
uncertain about the optimal method for transmitting them back to the
front end in a single response while also specifying the language for
each file. Would you be able to provide me with some guidance on this
matter? 🤔️
Closes: vercel#367
---------
Co-authored-by: Shu Ding <g@shud.in>
Currently the process of loading dynamic fonts for missing graphemes is, we use a list of RegExps to match that character, and use the first match as the final locale. Then, we go to Google Fonts and load that corresponding Noto Sans with that locale.
The problem is that these RegExps are not accurate. It might be not possible at all to generate RegExps for languages (or too large). For example we have
Han
in bothzh-CN
,ja-JP
, andzh-TW
andzh-HK
, but this is not always correct. In this example试
is only available inzh-CN
but is matched byHan
.We can step back and try to load the actual font instead, and check if that character (unicode) is included in that font. For example to render
试
, we matched["ja-JP", "zh-CN", "zh-TW", "zh-HK"]
. And then, we fetch corresponding Google Fonts CSS such as https://fonts.googleapis.com/css2?family=Noto+Sans+JP&display=swap and check theirunicode-range
to see if试
is included.I think this can be a more reliable approach.
Bug reproduction
The text was updated successfully, but these errors were encountered: