Why does font selection only rely on the Desktop's default LookAndFeel?


I wonder why anything related to font selection in LookAndFeel doesn’t follow the same rules that drawing methods do (e.g. with Component: checking if a LookAndFeel is set, if not, traverse the hierarchy, etc).

As far as I know (and do), if you want your custom getTypefaceForFont() method to be used, it has to be in a custom LookAndFeel that is then set with LookAndFeel::setDefaultLookAndFeel() (which sets the Desktop’s LookAndFeel).

But that means any custom font embedding and usage applies globally to an app and not on a per Component basis.

I suppose there might be a reason why it’s like this but I can’t figure out why. Any clue?

Many thanks!

First of all, you can create a font from a custom typeface. If your LnF returns those font objects, You’ll be able to do use custom fonts for JUCE Components that use the LnF.

Edit: see [Guide] Juce Font Embedding (2019)

Secondly the problem ist, that the Font objects somehow need to obtain the pointer to the LnF instance to then create the typeface. But because the Font objects don’t have a reference to the current LnF they are using the global one. Otherwise Font instances would always be coupled to a component or a LnF.

Thanks a lot!

I’m used to font embedding so no problem on this side.

My point was the “second problem”. I’d have excepted some sort of coupling, indeed, but that’s probably not the case for good reasons. Somebody else had the same issue: