Garbled Fonts - Mac

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.

However:

  • 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?

Here you go:

:slight_smile:

Ok - so renaming the fonts fixed it.

To rename the fonts I did this (on the mac using homebrew):

  • brew install fonttools
  • ttx Font.ttf
  • Edit the ttx XML file to rename every instance of the fonts original name
  • rm Font.ttf
  • ttx Font.ttx
1 Like

This certainly looks like a bug on our side, but I’m not having much luck reproducing it. I’ve tried installing the Rubik font, and then also including it as a binary resource and calling Typeface::createSystemTypefaceFor for each of the embedded font styles. Then, I’ve tried setting a new default LookAndFeel in both the DemoRunner and a custom plugin project, and setting the default typeface to one of the embedded Rubik variants. So far, nothing I’ve tried has produced the garbled-looking text from the screenshots. My suspicion is that JUCE is applying attributes from an embedded font to a different font loaded from the filesystem (or vice versa), but without being able to reproduce the problem it’s difficult to work out where that might be happening - or if it’s happening at all!

Do you see the same results with all renderers (CoreGraphics, Software, OpenGL), or only with specific renderers? Also, do you see different results in plugins to standalones?

I couldn’t trivally replicate it either.

One of my guys suggested that it might occur if you have multiple look and feel classes in a project. We have some UI classes which have their own look and feel - e.g. custom knobs. Possibly it confuses the hell out of some font cache somewhere … ?

That’s interesting. Do you have a program where you can consistently reproduce the issue? If so, could you try disabling additional LnF instances and check whether that fixes the issue?

(In case it’s not clear, I’m not suggesting that this is a solution to the problem, but it could be a useful data point to try and narrow down where the problem is coming from.)

1 Like

I’ll add some instances to my test program :slight_smile: Probably easier!

1 Like

That’d be great. Have you tested with different renderers? I’d be interested to know whether you can reproduce the issue with both the Software renderer and the CoreGraphics renderer.

Where’s the magic switch to swap renderers? :slight_smile:

Although presumably setFont only ever accesses the default look and feel? Because this is the only call to it:


static Typeface::Ptr getTypefaceForFontFromLookAndFeel (const Font& font)
{
    return LookAndFeel::getDefaultLookAndFeel().getTypefaceForFont (font);
}

Yes, I don’t see any other uses of that function, so I think the multiple LnF theory is a bit unlikely.

You can set the renderer like this:

if (auto* comp = getTopLevelComponent()) {
  if (auto* peer = comp->getPeer()) {
    const auto engines = peer->getAvailableRenderingEngines();
    peer->setCurrentRenderingEngine (engines.indexOf ("Software Renderer"));
  }
}

Alternatively you could create an OpenGLContext and call attachTo to attach it to your main editor component.

1 Like

Sorry to barge in, but I had similar issues in the past (garbled fonts or missing fonts) and while this could be totally unrelated, here are a couple of instances where the issues happened:

  1. In a plugin build I was using Desktop::setDefaultLookAndFeel. I was calling it from the constructor of the AudioProcessorEditor and passing a member pointer. But the desktop class stores the pointer globally, so if I opened 2 instances of the plugin and then closed the second one, the pointer would get lost into oblivion

  2. On Windows: Memory-based font not rendering properly on Windows - #7 by masshacker

  3. The good ol’ fun of multithreaded programming: I was accessing the same font from 2 threads at the same time

I’m not sure whether this can help or not, just throwing the info out there.

Ah right, so we are using the OpenGLContext::attachTo setup on the mac. Disabling it results in the fonts rendering correctly. I’ll try my test program again :slight_smile:

1 Like

Aha, that’s very interesting! It sounds like something is broken in JUCE’s own rendering code, in that case. I’ll try reproducing the issue with an OpenGL renderer.

1 Like

If you can’t repro, check you PMs :slight_smile:

Thanks for all your help in tracking this down. The issue should be resolved by this patch:

1 Like