Text Alignment differences between JUCE 5.4.4 and 5.4.5

To avoid this kind of regressions, maybe some simple Unit Tests could be added.

They could work like this: create one temporary instance of the Component to test, give it some default bounds and meaningful appearance properties, then take a snapshot of it using the software renderer (thus ruling out any system-dependent variance) and compare it with a known reference image previously taken with the same method.

1 Like

I’ve fixed an issue with glyph alignment here:

Has this restored the vertical alignment?

I just incorporated the fixes, and sadly, it does not fix the issue. The text is still down 1 pixel, no change.

Here’s a test GUI App with those two little buttons in it, and some positioning code copied from my app. I just tested it with both 5.4.4 and 5.4.5 and the issue is reproducible. Hope that helps!

TestButtonText.zip (5.2 KB)

Thanks for that. Code samples almost always help track something down.

Whilst we didn’t intend to change text positions between 5.4.4 and 5.4.5, the slight downwards shift actually brings the CoreGraphics renderer and the software renderer into alignment; the behaviour of the software renderer has not changed and in 5.4.5 the behaviour of the CoreGraphics renderer now matches the software renderer. So, this change was really a bug fix, rather than a bug itself.

However, had we realised that the CG text rendering would different we would have listed it in the breaking changes doc. Since most people will be using the CG renderer on macOS then there’s a decent case to be made for now making both render text a bit higher.

1 Like

Still worth adding this to breaking change though.

Thanks, but what about the fact that it now looks wrong? It’s not vertically centered any more! It looked better before.

Am I supposed to custom-look-and-feel this everywhere? Maybe I just need to make my buttons a pixel larger or something, will have to experiment.

But it’s clearly not perfectly vertically centered now in this example. If the software renderer has not changed, then it is [has been] wrongly vertically positioning the text.

Sorry, I missed that in my first comment. I hope you will consider making this fix! Thanks.

I’ve had a look at what we’re doing and we’re not going to make any further changes. I’ll update the breaking changes doc.

As some evidence that JUCE is now doing the right things, here is a html button in two different sizes using the same font (Apple’s San Francisco) rendered in Safari:

safari_button Screenshot 2020-01-21 at 09.23.53

And here’s a (zoomed in) JUCE button using “Courier New”:

I’ve no idea if Courier New has a particularly centred ‘+’ character, it was just the first other one that I tried.

I may be missing the point, but why are you not comparing Safari and JUCE buttons using the same font?
If they both appear to have the same alignment, then yes, it’s an indication that JUCE is aligned (pun intended) with the standard.
But using different fonts with, potentially different baseline/alignment, seems to miss the point

There were already some screenshots showing how the JUCE rendered the ‘+’ slightly below the centre in the first post. I was just showing that it’s a property of the specific font used, rather than a persistent bias from JUCE. Here’s San Francisco:

1 Like

So ultimately, what is the reason that the default font in JUCE is apparently not properly vertically centered on Mac OS any longer? It’s Apple’s issue?

I guess one would have to custom-look-and-feel everything to overcome this issue…?

The default font JUCE uses on macOS is the same as that used by the rest of the operating system - San Francisco. That’s not going to change,

Your question then becomes: why is the apparent vertical centre of the SF font slightly lower than where you would expect it to be? Presumably this is because Apple decided that is what looks best in most situations. You cannot access what the vertical center of a font is meant to be using the macOS font API, and I’ve not seen it specified in any other font definitions. The best you can do is to center the font’s bounding box in the middle of the button (which is what web browsers and JUCE do).

Using a different font is one way to go, or a custom look and feel for drawing the text on your buttons.

I just debugged into that button example I posted earlier in the thread, and the default font that comes up for me is “Lucida Grande”. Where are you getting San Francisco?

I should mention I’m on Mojave…

I’d assumed we’d get the same font as the rest of the system. JUCE simply presents the default sans serif font.

It turns out that Lucida Grande has almost identical vertical alignment to SF. Just substitute ‘Lucida Grande’ for ‘San Francisco’ in all the previous posts.

Where exactly is that? Thanks.

At root level of the repository:

Just wondering if there is not something wrong there

 label.setText("Doppler", juce::dontSendNotification);
  label.setBounds(100, 100, 74, 22);
  label.setColour(juce::Label::outlineColourId, juce::Colours::red);
  juce::File file("/Users/otristan/Desktop/BugJuce/bugFont/DIN_COND_BOLD.ttf");
  auto pStream(file.createInputStream());
  if (pStream)
    juce::MemoryBlock data;
    juce::Font font(juce::Typeface::createSystemTypefaceFor(data.getData(), data.getSize()));

On OSX the following code renders like that
Screenshot 2020-05-15 at 16.10.16

Doesn’t look very centred vertically.
Using juce6 branch FWIW

Here is the font
DIN_COND_BOLD.ttf (84.5 KB)

in our production code we still use the old FreeTypeAmalgam custom font loading and display from TheVinn (Vinnie Falco) which displays the content centredLeft
Here is an example of the difference between the two
Screenshot 2020-05-15 at 16.13.48
Juce with createSystemTypefaceFor
Screenshot 2020-05-15 at 16.14.16

Any ideas ?

Thanks !


I’m hitting that kind of issue with another font in another product on OSX
Screenshot 2020-08-21 at 11.09.29

This is clearly not vertically centred.
Honestly there is something fishy here.

Here is the font used
AvenirLTStd-Heavy.ttf (30.0 KB)

Finally found the issue