This seems to be similar to previous issue I have seen (Weird behaviour with in-memory fonts and OSX Layouts) but I am trying to move from JUCE 4.2.1 to JUCE 5.3.1 and I am getting off-by-one characters in the test of popup boxes.
How to reproduce:
- Open DialogsDemo
- Add roboto ttf to the project (so it goes in BinaryData)
- Add a look and feel class
class LnF : public LookAndFeel_V4
roboto = Typeface::createSystemTypefaceFor(BinaryData::fonts__roboto_ttf, BinaryData::fonts__roboto_ttfSize);
You will notice that the characters are a mess and they seem to be off by one character.
This bug was already reported in Bug with Alert Window text and embedded fonts in 5.3.1, but unfortunately it doesn’t seem there is a fix yet…
@harrycodex could you try reverting commit 2e0f6b5dbccde550c4f9b9ed85f04009b61789b8 in JUCE and see if that fixes the issue? I unfortunately don’t have a Mac at hand to try that now…
I have just tried on my Macbook and I cannot reproduce it. I will try on the Mac Pro when I get into the office in the morning. Weird. Both machines are 10.13.4 with latest release XCode and SDK
Thanks for the bug report. Reverting commit
2e0f6b5dbccde550c4f9b9ed85f04009b61789b8 does indeed fix the bug. We’ll get this sorted…
OK. This is fixed on develop with commit
f639b7b. This will appear on the public repo in a few minutes.
Sorry for bumping this topic, but i maintaining a legacy software build with an older juce release (4).
And the weird thing there is a coincidence, an ascii-character offset of minus two (not plus) but on windows and in conjunction with AttributedString, not reproducible here, but on a customer pc with windows 10.
It doesn’t seem to be a general issue, only on that one particular customer pc.
No custom or in-memory fonts, just the system font. If anybody has the slightest idea what this could be, this would be interesting for me.