Still having fun trying to display non latin text and I've encountered an issue which happens on OSX and Windows.
If I load a TTF font using createSystemTypefaceFor and use it with TextLayout, it nevers fallback to other fonts if the glyph is not available.
On Windows, it's probably related to the fact that createSystemTypefaceFor (const void* data, size_t dataSize) don't have the implementation
using DirectWrite and fallback font only works in that case. See TextLayout::createNativeLayout and canAllTypefacesBeUsedInLayout returning false.
On Mac, there is a comment line 1300 in juce_mac_fonts.mm
// Seems to be an unfathomable bug in CoreText which prevents the layout working with
// typefaces that were loaded from memory, so have to fallback if we hit any of those.
So my questions are,
1) Is this possible to implement on Windows ?
2) Regarding OSX, did it only happened on some versions of OSX ?
Yeah, this is a really messy area, as all the OSes and font APIs seem to have different quirks that fail in different ways - I can't honestly remember all the ins-and-outs of them all..
This has always been a really difficult area. Font layout is too vast a task for us to be able to implement it ourselves, so we need to rely on the OS functionality to do it, and to tell us which glyphs should be drawn, and IIRC there were places in the OS functionality that just didn’t work correctly under some circumstances, in-memory fonts being an example.
I can take another look into this, but it may be something where there just isn’t a fix. You’re struggling with OSX in particular?
Thanks Jules. I totally understand that this would be very difficult area to wrangle for all platforms.
In our case, we are currently struggling with OS X: using custom fonts for most everything in the plugin but also not wanting to restrict users who might have a non-latin character in their name, preset name, etc. (in TextEditors & elsewhere), and we’re planning on some internationalization as well.
We have a hacked workaround, but I’m wondering if there are any better options. At the moment, we parse all AttributedStrings and rebuild them by filtering out any unicode values above something like 0x02C9 and creating a new attribute with “Arial Unicode MS” as the font for those values. This works fairly well — we get the custom font when available and Arial for everything else — but obviously it’s very inefficient. What’s more, it doesn’t work for something like a TextEditor where we can’t directly fiddle with the font for each character.
I remember seeing that you said the issue with OS X is that it doesn’t correctly report when glyphs are missing? In our case, since the font is a font we’re providing, we know all the glyphs that won’t be available. Is there some way to use this information to provide fallback support at a lower level than we are currently?
Any news on this ?
I cannot have fallback font as soon as I am using a custom font.
This is really a deal breaker for Japanese people which represents a lot of our users.
Please note that the same kind of issue happen if you have a text in a juce::TreeViewItem where you need its width
which will depends on the font used.
In the meantime, I can have a code that do not set the custom font if the text contains non supported character, but is there a way to detect this ?
The same kind of trick could be eventually used in TextLayout FWIW
Would be great if you guys can figure this.
I’ve made some hack so far which detect if a string have some non latin and usual character and don’t use my custom font in that case, but this is far from perfect.
Having at least a way to query a font to know this would be great.
Something like a public findGlyph.
As a side and a bit related if you can’t make this work with pure juce custom typeface, it would be great if Typeface::createSystemTypefaceFor Windows implementation would have a DirectWrite version
as it would allows the automatic fallback to probably work.
Funny thing regarding this latest point.
if I call boldened() on the font containing this WindowsTypeface, the new one becomes a WindowsDirectWriteTypeface
but don’t look much like the original font.
This is a bit weird.
