Consider a new way to load dynamic fonts #367
Assignees
Labels
Comments
|
I'm interested in it! Can you assign it to me? <3 |
|
Sure, @LuciNyan thank you and feel free to explore this! |
|
🎉 This issue has been resolved in version 0.4.10 🎉 The release is available on: Your semantic-release bot 📦🚀 |
sahithyandev
pushed a commit
to sahithyandev/satori
that referenced
this issue
Apr 26, 2024
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>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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
Hanin bothzh-CN,ja-JP, andzh-TWandzh-HK, but this is not always correct. In this example试is only available inzh-CNbut 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-rangeto 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: