Garbled Fonts - Mac

We have some users who get an issue with garbled fonts. We have embedded the font in the app.

The users who have the issue also have the same font installed on their computer. When they remove it from their computer the problem goes away.

This affects multiple MacOS versions.

Anyone got any clues?

[I have noticed in one of our other plugins previously that if a dialog box appears before default LookAndFeel is set up and the typeface returned for a specific font changes this problem occurs. So maybe that’s a clue… but I think we are setting up the LookAndFeel pretty early in the app with the problem]


Are you able to check if they have the font installed and if so use that rather than your in-memory version?

We see this occasionally too but I don’t know how to trigger it and I wasn’t aware of the above pattern.
Come to think of it, I’ve not seen this since I got a new machine and probably don’t have the font installed on it so maybe that was the cause :thinking:

1 Like

Ah - that is a good backup plan.

I’ve jsut found Typeface::clearTypefaceCache() so I’m going to try that directly after setting default look and feel first!

1 Like

I think we do that already. It might have helped a bit…

“Helped a bit” :). Love these kinds of problems :slight_smile:

We have a bunch of customers who can repeat it every time. So I’ll pop this in the build and see if it fixes it for any of them.

I also moved room to one with more sunlight. It might have been that which helped. :wink:

1 Like

Oh, absolutely.
I also noticed that those pesky bugs thrive in the dark and hate sunlight :grinning_face_with_smiling_eyes:

What is your Typeface::Ptr getTypefaceForFont(const Font& font) implementation?

Typeface::Ptr LcLookAndFeel::getTypefaceForFont(const Font&f)
	if (f.getTypefaceName() == "OriginalSystem")
		return LookAndFeel_V3::getTypefaceForFont(Font());
    if (f.getTypefaceName() == "Monserrat-Regular")
        return monserrat->regular;
    if (f.getTypefaceName() == "Monserrat-Medium")
        return monserrat->medium;

	if (f.getTypefaceName() == "Monserrat-Semibold")
		return monserrat->semibold;

	if (f.getTypefaceName() == "Monserrat-Bold")
        return monserrat->bold;

    if (f.getTypefaceName() == "<Sans-Serif>")
        Font font (f);
#ifdef JUCE_MAC
        font.setTypefaceName ("Helvetica Neue");
        font.setTypefaceName ("Arial");
        return Typeface::createSystemTypefaceFor(font);

    return LookAndFeel_V3::getTypefaceForFont(f);


Recently, I ran into garbled embedded fonts on macOS. I had an implementation logic similar to yours. Somehow, I found out the returned embedded typeface had to be consistent with the requested Font.

if (f.getTypefaceName() == "Montserrat" && f.getTypefaceStyle() == "Regular")
    return montserrat->regular;

I supposed you’re using Google’s Montserrat font (with an extra T :wink: )

Oh good spot! I’ve probably spelt that about 15 different ways so far :slight_smile:

Usually I called it Monster Rat :slight_smile:


Let me know how it goes.

Withdrew initial question – thanks for the fix!

I’ve got this problem again Check out my status bar.

This one is Font() and Font().boldened() passed into AttributedString() with the default sans-serif font overridden in LookAndFeel.

I don’t suppose the JUCE team could look at making this either easier to debug or harder to break?

I’ve got another two different font issues in a different standalone app on Windows as well…and I’m shooting in the dark a bit!

This is AttributedString every time I think.

In some cases I can get this where Font(“Rubik”…) renders correctly but Font(“Rubik”…).boldened() does not!

I’ll see if I can make a simple test app that shows the problem.

1 Like

fwiw someone (@pflugshaupt perhaps?) mentioned in another thread that editing the font to give it a custom name can solve this issue, but a more comprehensive fix would be better I think.

Is this an OS-specific issue? Or is it happening both on macOS and Windows?

Ok so my notes so far:

  • Building a test app has so far failed to replicate the problem - I can only replicate it in more complicated plugins and apps.
  • Removing getTypefaceForFont() and instead calling setDefaultSansSerifTypeface(rubikRegular) does not solve the problem. So this rules out any failures by me to implement getTypefaceForFont properly, and I think pretty much firmly puts this in as a JUCE bug!
  • Using Font() default font causes the problem with regular and bold. Changing to a named font “Rubik” fixes the problem for the regular font but bold is still broken!
  • Setting the LookAndFeel at the start of my PluginProcessor before anything else has happened fails to fix the problem.


  • Changing the bold font from Rubik Medium to Rubik Bold has fixed the bold text
  • Doing this and specifying “Rubik” instead of using Font() also fixes it for the regular font

Conclusions so far:

  • Under some circumstances which are pretty hard to replicate JUCE’s default font system does not work correctly.
  • Specifying exactly the correct font name and weight seems to work, assuming you choose the same font as the system would in your getTypefaceForFont call.
  • Overriding typefaces with your own in getTypefaceForFont is risky, what happens if the user has a different version or, or different font under the same name on their system.
  • Removing the typeface from my system also fixes the problem.
1 Like

I have similar issues on Windows although with different software and on customer computers not mine.

Right - I now see what you mean by this. Actually modifying the embedded font file. I think that should work, just trying to get the right tools installed to try it.

@jimc just wanted to comment on the GUI of your plugin. Looks great. Wondering which plugin this is so I check it out?