Support font/glyph substitution if a font does not have all characters needed

[ghost]

Is your feature request related to a problem? Please describe:

Unicode depiction is a big problem in Fyne. While going down the rabbit hole as deep as the freetype library goes,
I am of the opinion that the Go port of freetype might be missing some features. Because the NotoSans font
I loaded by using FONT_FYNE was able to depict some Unicode characters, but not the ones that I needed (Chinese characters). But since I am not a 100% certain about this because I can never prove it because this research already was way over my skill-level, I think my suggestion made here might be a good compromise.

Font/glyph substitution could fix this since every modern GUI toolkit since 2003 uses this. Even Tkinter since a few years now. In Tkinter I can show all UTF-8 characters independent of the font (this is can be proved with a small program).

Is it possible to construct a solution with the existing API?

It is actually not because Fyne does not allow every widget to be configured in all its details,
because Fyne's philosophy is to let the OS driver handle everything which in turn only
allows a theme for an application that influences the look of all widget and the application.

However Fyne should respect use cases were people i.e. create a Flashcard app for vocabulary training.
The most important widget of a flashcard of course is the label widget that shows the flashcard's text. Let's say I
need to draw traditional Chinese characters (Cantonese), this is unfortunately currently not possible with Fyne and NotoSans family.

A user should not be forced to load a specific font for this because it will influence ALL widgets. So I am saying
that there are good use cases were some parameters of a single widgets in the application should be able to
configured independently of other widgets.

Here we could achieve this with said font/glyph substitution.

IMHO this also goes for other parameters of said flashcard label, but I will not go into this here because it is off-topic.

Describe the solution you'd like to see:

Implement font/glyph substitution (I don't really know the correct technical term). This means if a font does not
provide a character it will be substituted by a character from another font that provides it. See Tkinter and
many other GUI toolkits for example.

I would really like to avoid to hack together a Fyne application that fulfills my needs by usind dirty teqniques like for example reflection.

[andydotxyz]

I think we already do this. If you load a custom font, such as chinese, then items not found in that font will be rendered using our built-in font instead.

Can you be more specific about what is not working for you so we can step through what is missing?

[andydotxyz]

There is more discussion on go-text/shaping#8, but as mentioned above I think we have this implemented already.
Any more information would help us to understand.

[dweymouth]

I think the long term goal here would be for Fyne to be able to discover fonts installed on the OS, and use multiple fonts (ie more than just two - the theme font and Fyne builtin font) to render characters if glyphs are missing from some of the fonts. This is how web browsers and mature toolkits like Qt do it. This should eventually become possible as the go-text project evolves more, and could solve other issues like emoji support #573 (discovering and using the OS-installed emoji font).

[UrbiJr]

I think the long term goal here would be for Fyne to be able to discover fonts installed on the OS, and use multiple fonts (ie more than just two - the theme font and Fyne builtin font) to render characters if glyphs are missing from some of the fonts. This is how web browsers and mature toolkits like Qt do it. This should eventually become possible as the go-text project evolves more, and could solve other issues like emoji support #573 (discovering and using the OS-installed emoji font).

need this 😐

[andydotxyz]

Same as #1579 - the fix is in PR #4721 and should be in v2.5.0

[dweymouth]

This has landed on develop for 2.5.0