Hi,
I am currently scratching my head about this: as I don’t have all characters in my font that Apple Game Center allows for player names (basically everything…), I need to show something nice as replacement character for those. So I chose ✮ as replacement for any fancy characters that players chose to still show player names in a nice way in my game. And it looks pretty good. However sometimes two replacement characters are shown for just one missing unicode character. Examples:
- “Katy” is correctly displayed as “Katy✮” (Unicode U+1F496 – I am just noticing in the preview that the editor does show the sparkling heart here, but the final post doesn’t, so imagine a pink heart behind “Katy”
…)
- “Coffee
” however is displayed as “Coffee✮✮” (Unicode U+2615), so with two replacement characters
I looked at the actual data coming back from the server in the logs, and there are no other hidden secret characters. You can actually copy the text above between the quotation marks to check out in a TextMesh Pro sample text for verification…
@Stephan_B Any clue why this happens?
In the text “Coffee”, the “” is composed of \u2615 + \uFE0F which is a variation selector to indicate the preceding Unicode \u2615 should use the color version of the emoji whereas \uFE0E would indicate to use the monochrome version.
You could filter the incoming string to remove these Unicode selectors. The format is Unicode for emoji followed by Unicode selector.
Ok, understood. But then, does it make sense at all to replace a variation selector with its own replacement character? It would never be in the font anyway, so you could either just leave it as it is (and so modify the replacement character to be a color variation also), or just drop it after having replaced the predecessor.
N but on the other hand, I can’t simply remove it either as those are two distinct characters.
It is best for the user to handle such filtering until I get around to adding support for Ligatures which internally replaces /u2615 + /uFE0F by a single glyph of the color coffer mug.
Well, so then I‘ll try that. But this has to be done for every non-spacing character, because each is just annotating/modifying the previous. From the user perspective a second replacement character does not make much sense. Initially non-spacing, it now takes up space of one additional character. Better would be IMHO to optionally have a second replacement character that would reflect a combined missing character with modifier (if you feel the user needs to know that, which tbh I doubt…).
BTW: how do I know which character will not be available, so that I can safely remove a subsequent modifier at all? Isn‘t that something only „you“ know during final processing?