Font height issue/question


My font height is really different between OSX and Windows :
I thought that a given font size would lead to the same result on win and osx, but if I just do setFont (15.f), then the height is much much smaller on windows.
To have the same size, I have to use withHeightInPoint (15.f).


Is that expected ? Or why is that? Is there's a workaround?
It's a bit annoying, as I have to call withHeightInPoint in all the lnf functions that draws text.

btw, I'm using my own font :


typefaceFromBinary = Typeface::createSystemTypefaceFor (FontBinaryData::MyFontRegular_otf,
                            FontBinaryData::MyFontRegular_otfSize);

Typeface::Ptr MyLookAndFeel::getTypefaceForFont (const Font& font)
{
    return typefaceFromBinary;
}

Haven't noticed that myself.. In things like Tracktion I use a common embedded font on different platforms and it has generally been consistent.


If it can give any clue : when I look at Font (15).getHeightInPoints(), I got 15 on osx, but only 10.9729 on Windows.
Any idea what's the origin of such a small value, or what I could look at ?

I don't think it changes anything (?), but just in case, I build my plugin with parallels under a retina mac.
 

If you do Font (15) you'll get the default system font, which will be different on windows and OSX (?)

I looked at it this way in fact, in the drawLabel (Graphics& g, Label& label) :

Font f (getLabelFont (label));

DBG (label.getName() + " : " + String (f.getHeight()) + " - " + String (f.getHeightInPoints()));

But the displayed font is definitely the right one, not a default one. It is just much smaller on windows.

Not the same DPI on Windows and OSX

 

some informations there

http://www.rfwilmut.clara.net/about/fonts.html

 

If you want the same height, do not use points size.


<blockquote>If you want the same height, do not use points size.</blockquote


I think I misunderstand something here, cause I got the same size if i use point size, not font height : 

Size is smaller on windows if I do :

void drawLabel (Graphics& g, Label& label) override
{
    g.fillAll (Colours::darkred);
    g.setColour (Colours::black);

    Font font (getLabelFont (label));
    font.setHeight ((float) label.getHeight());
    g.setFont (font);
    Rectangle<int> textArea (label.getBorderSize().subtractedFrom (label.getLocalBounds()));    
    g.drawFittedText (label.getText(), textArea, label.getJustificationType(),
                          jmax (1, (int) (textArea.getHeight() / font.getHeight())),
                          label.getMinimumHorizontalScale());
}


But everything is fine if I just add withPointHeight() :

void drawLabel (Graphics& g, Label& label) override
{
    g.fillAll (Colours::darkred);
    g.setColour (Colours::black);

    Font font (getLabelFont (label));
    font.setHeight ((float) label.getHeight());
    g.setFont (font.withPointHeight ((float) label.getHeight()));
    Rectangle<int> textArea (label.getBorderSize().subtractedFrom (label.getLocalBounds()));    
    g.drawFittedText (label.getText(), textArea, label.getJustificationType(),
                          jmax (1, (int) (textArea.getHeight() / font.getHeight())),
                          label.getMinimumHorizontalScale());
}

Do I make any mistake here, or is the result what you would expect?

 

edit : attached screenshot (above is win, below osx), done with the first drawLabel() method above.

notice as well the quality difference !

Are you sure it's not because you use drawFittedText which will shrink your font when it's too big.

So in your case it works fine because the font is bigger in both case than your label height.

yes, I'm sure. even if I reduce the size it's the same.

you can also see on the screenshot that the same happens with the window's title text "MainWindow".

ok, the problem was really with the particular font I'm using. no problem with most of the fonts.

What could be wrong in an otf file that can lead to that? that was increasing a lot the creation time of my editor on windows as well.

So my best bet is to change the font I'm using I guess...

Font files can be pretty complex, maybe there's something quirky about it that leads it to behave differently in the different font engines.

I had exactly the same problem, and it drived me nuts. Everything seemed to be fine with some default fonts, but when I used fonts from embedded OTF files, I had to write different font heights for Windows and for Mac OS X so that the display is consistant. I wonder if it is something about the font itself and the font engine, or maybe something about OTF files reading ?

My guess is that it must be differences in the underlying engine, because at the level that the juce classes work, all fonts are presented in essentially the same way.

I guess its my turn to hit this one. Fonts in Windows just seem to come out smaller than on macOS.
Examples and test case repo here: https://gitlab.com/dave.ursa/JuceFontTestCase/tree/master/ScreenShots

I guess the bit that confuses me the most is that Juce knows there’s a difference via Font::getHeightInPoints()

Is there a preferred way to get past this? I’m trying to avoid code path differences between Mac and Windows.

Thanks for any info,
Dave

Jules says he was embedding a font and getting similar results. I find even if I do that Windows renders the font a bit thiner than MacOS and I need to do some tweaks - I’ve ended up with a couple of utility functions that get me the correctly adjusted font for the platform in the end…

Cheers jimc,
Do those two screenshots look similar to your discoveries or have I just picked two very unlucky fonts?

I have since discovered Font::withPointHeight() which seems to go much of the way there. I’m still getting more space between rows of text on windows, but I’m less worried now about having to use successive approximation.

If I end up with something reliable in a general sense I’ll submit it here.

Dave

I was working with much smaller fonts - but relatively those differences don’t look surprising. What fonts are they? I found that the vertical alignment was a pixel out once as well when it mattered… :slight_smile:

Leander and CooperHewitt semi bold. Fonts and licences are in the example source: https://gitlab.com/dave.ursa/JuceFontTestCase/tree/master/Source

All discovered via fontsquirrel which is quite handy for finding fonts with suitable licences to embed in apps.

1 Like

I’m running in to this size issue the same as Dave above where he has already posted pictures of the large size differences between Windows and Mac OS.

I think some people are confusing this issue with the slight OS related rendering differences in apparent thickness where in fact this specific issue is much more evident see Dave’s pictures 5 posts up.

The fonts I’m using show this problem in both otf and ttf formats and only with juce. A quick debug through leads me to believe the edge tables are generated at the wrong size/position on Windows pre transform.

Mike.

2 Likes

Even with basic Times New Roman here on OS X, a font size of 100 does not result in a letter being 100px from top to bottom:


ProJucer component size is visible in the lower RH corner if you click on the picture.
what is happening here?
I’m expecting a font with a height of 100 to be 100px from top to bottom.
:thinking::thinking::thinking: