However, I realise there is an additional mapping necessary. By outputting tables of glyphs, I could figure out an offset, but that is not consistent, neither within one font, nor across fonts (I am comparing bravura and petaluma, both publicly available).
Now I found the character map, but no information, how to access that, nor could I see in the JUCE code, that it uses that anywhere.
So how can I map from the smufl codepoint to the glyphnumber the Typeface expects?
Thank you @roeland. That is the workflow for characters and how to get the glyph numbers and the kerning of proportional fonts.
The problem of the positions of the glyphs is well documented in the SMuFL definition and metadata for anchor points, so Daniel Spreadbury and the team did a great job here.
But the glyphs are defined by a number “codepoint”, they are no characters.
Like I wrote above, I found blocks matching with an offset, but no consistent way to compute the glyphnumber from the codepoint other than looking at the table, and I would have to verify every single glyph in any font I want to use, so this is not an option.
I was digging a bit further, CustomTypeface has a private method called “findGlyph”, but it fills a lookup table with the size of 128 glyphs. I have a hunch, that JUCE actually can only deal with Latin-1 characters. Should that be true? I can’t believe that…
Yes, they are unicode code points in the PUA, but I am missing the mapping from codepoint to glyphnumber, which is not the same. JUCE offers me to get the glyphnumbers for a text (and therefore for single characters), but not from codepoints, or am I missing something?
Wild guess - try using code points below 0xffff. Code points above 0xffff must be converted to UTF-16 surrogate pairs. Smufl fonts must be able to handle UCS2 (utf16 without surrogate pairs, or Unicode BMP) anyway (as per specification).
Indeed, that yields the right result! Thank you so much @perob. Some of the code points are not in the PUA, so I can use them directly.
I also realised, that I need to specify multiple bytes for the PUA, so I will have to look into encoding the actual bit patterns.
I would have hoped not to use the getGlyphPositions, since it does additional work that is not necessary, i.e. the layout for the individual characters, but it’s probably not too bad, since I will give it single characters anyway.
Thank you so much (and all others that provided pieces to the puzzle).
I still hope my FR will get addressed, since it will make the API and my code much more concise, but at least it seems I am no longer deadlocked.
That is not expected. A fragment like this should yield one glyph, a smiling face in this case. Whether or not to generate multiple bytes is handled internally by JUCE.
String s = String::charToString(0x1F603);
// pick a font which actually has that character: 😃︎
Font font("Segoe UI Symbol", 20.f, 0);
font.getGlyphPositions(s, glyphNumbers, glyphOffsets);