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
Fonts which aim to have support for as many languages as possible (Noto, IBM Plex, etc) break their font up into multiple files for the different languages. Emojis, as well, are often in a separate font file to the primary font file.
Current workaround
The only solution I am aware of at the moment would only work for text labels and not user inputted text. The solution would be to have separately named fonts for each language and then read through the text to be rendered and break it up into chunks for each language and then render each chunk in a separate label with the appropriate font. This induces additional problems like that line wrapping must now be dealt with by the developer and is overall a very outwardly complex solution
Proposed solution
Within the same font name (i.e. "Regular") the font manager should be able to fall back down a list of font files if it cannot render a glyph with the primary font file. This would not incur any additional complexity to application developers while solving the issue.
The text was updated successfully, but these errors were encountered:
The Problem
Fonts which aim to have support for as many languages as possible (Noto, IBM Plex, etc) break their font up into multiple files for the different languages. Emojis, as well, are often in a separate font file to the primary font file.
Current workaround
The only solution I am aware of at the moment would only work for text labels and not user inputted text. The solution would be to have separately named fonts for each language and then read through the text to be rendered and break it up into chunks for each language and then render each chunk in a separate label with the appropriate font. This induces additional problems like that line wrapping must now be dealt with by the developer and is overall a very outwardly complex solution
Proposed solution
Within the same font name (i.e. "Regular") the font manager should be able to fall back down a list of font files if it cannot render a glyph with the primary font file. This would not incur any additional complexity to application developers while solving the issue.
The text was updated successfully, but these errors were encountered: