The text “Rattle and roll” renders as “Rattle nd oll” with the third party font I’m using.
Funky! Not 100% sure what the exact mechanics are, but the presence of “tt” seems to result in the first character of all following words being dropped.
User reported and I reproduced in a brand new project. I saw the behavior on JUCE 7, develop, 6.1.6, 6.1.2 with juce::Label and g.drawText. We’re both on M1 MacOS 15.4.
It happens with the .otf and the .ttf.
It doesn’t happen with the default font.
Was thinking maybe it could be triggered by a ligature, but can’t get any other combo than “tt” to trigger it!
I love this font and I’m pretty committed to it with this product. Happy to DM it to the team if they can’t reproduce…
The type designer ended up providing absolutely amazing support, even looking into JUCE’s documentation.
He wrote the following:
CALT is a standard OpenType feature, I believe it’s been there since the beginning (at least since 1.4). Support has been good everywhere I’ve ever tested it, though it’s a little rare to find in other fonts (it’s most commonly used in script typefaces). From a text engine pov, CALT should be on be default.
It seems like we’re having trouble with the first lookup. If the other lookups are working correctly (‘f’ followed by an ascending character, ‘j’ after a descending character), then it seems like Juce is tripping up on the many-to-one substitution.
He provided me with some alternative builds of the font that fixed my short term issue of needing the characters combinations to render properly in JUCE.
He also pointed out that JUCE has a few typographic concepts confused, swapping the definition of ‘font’ and ‘typeface’ and using ‘kerning’ to mean tracking/letter-spacing.
I’ve just run into this same issue with a third-party font I’m committed to using, where the combination of “less than” or “greater than” with a dash ( <- -> ) gets turned into a left arrow or right arrow ligature, and when that happens, other characters in the popup menu I’m trying to populate get dropped.
Did you ever find any other solution besides having the font developer modify the files?
I tried removing the ligatures/characters with FontForge and regenerating the font, but it’s not working right… I clearly don’t know what I’m doing and that tool is really complicated for someone who is not a Font developer.
It would be cool to know more details about this, as I think that all frameworks get limited by their misunderstanding of typography at some point (happened with MOAI too at one point…)
I also had that issue, removing the characters with fontforge did help for me. Right-clicking on the bad glyphs and clicking “clear”, to be precise. There are quite a few you need to clear, basically all the arrows:
But yeah, fontforge can be a pain. I’ve been using it for a few years now, you’ll get used to it eventually. Fontlab is a nice alternative, but it’s not free.
Thanks, I did clear the characters, but then what? You regenerate the font, correct? When I tried to do this, it gave me all sorts of warnings about things that I have no idea how to fix, so I just plowed ahead and the newly generated font does not look the same as the original in certain aspects. It wasn’t as simple as just deleting several characters…
By the way, I made a bug report post about this, because ultimately, the TextEditor displays these ligatures correctly but the ComboBox does not, so it should not be up to modifying the font to correct this issue:
Oh yes, I did File → Generate Fonts and exported as ttf. It also gives me all kinds of warnings, but if you just click okay on them, everything works fine for me.
But yeah definitely report it, it’s strange that it works on some cases and not in others. I believe the JUCE team are working on improved unicode/fallback support, maybe that will help with this issue too.
Thanks - based on your reported success, I took another look at it and managed to export a fixed font file that looks the same and has those arrows removed. At least I can use this instead of or until the JUCE team fixes it.
Wow really interesting to know other people ran into similar issues!
Mainly some nomenclature mixup, seems like. “Kerning” in JUCE is actually “letter spacing” or “tracking”, more here.
Typeface (or font family) usually refers to a collection of fonts (style/weight implementations of a typeface). I think maybe he was indicating JUCE’s Typeface class should be called “Font” since it’s literally an implementation of a Typeface in a particular style (aka a font). Typeface is used correctly in some places, such as getTypefaceName and incorrectly in others (getTypefaceStyle). I’m not sure what JUCE’s “Font” class would then be named, “FontSize” or something, but basically those classes are fast and loose with what “font” and “typeface” mean in naming and documentation.
