Creating a juce::Typeface from a static font file using juce::Typeface::createSystemTypefaceFor() results in the typeface name including the font’s style.
E.g.
const auto notoSansJP = juce::Typeface::createSystemTypefaceFor (NotoSansJPRegular_ttf, NotoSansJPRegular_ttfSize);
DBG(notoSansJP->getName());
Outputs:
Noto Sans JP Regular
This has a knock-on effect on Windows where a juce::WindowsDirectWriteTypeface fails to load the font as IDWriteFontCollection::FindFamilyName() (here) is expecting just the family name (i.e. it expects "Noto Sans JP", not "Noto Sans JP Regular").
For non-latin fonts, this means juce::TextLayout fails to create a native layout and so tries to create the layout itself which appears to be very flawed.
I think the guilty party is “TTFNameExtractor”, and its a Windows thing, because on MacOS it seems Name and Style are treated uniquely, whereas on Windows some hack is required to get the name … although I don’t see where the Style is being globbed into the string, so it could also be Font-specific? Does it do this with all fonts?
Lots has changed in the font handling on the JUCE 8 branch, especially around fonts loaded from memory on Windows, so I’d recommend upgrading and testing again. At this point we’re only fixing critical bugs on the JUCE 7 branch.
JUCE 8 uses HarfBuzz for text shaping, and will remove the support for DirectWrite and CoreText ‘native’ layouts. This means that the same text shaping engine will be used on all platforms, improving layout consistency. At time of writing, only GlyphArrangement has been updated to use the new HarfBuzz shaper, and TextLayout is yet to be updated, though I expect this change to be made public in a few days.
Yeah I thought that might be the case! Gave it a quick spin on JUCE 8 and it looks like juce::Typeface::getName() is correctly only giving the font family name (on macOS, with the handful of font’s we’re using, at least).
