Garbled Fonts - Mac

21

Here you go:

:slight_smile:

22

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
23

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?

24

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 ā€¦ ?

25

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
26

Iā€™ll add some instances to my test program :slight_smile: Probably easier!

1 Like
27

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.

28

Whereā€™s the magic switch to swap renderers? :slight_smile:

29

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);
}
30

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
31

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.

32

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
33

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
34

If you canā€™t repro, check you PMs :slight_smile:

35

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

1 Like