While implementing emojis to a custom texture pack i found that Unicode characters are being rendered with a gap in between using their specific Unicode designations. This is resulting in somewhat undesired behaviour as it is rendering a big old line straight through the character.
[media]Code for the Bitmap provided Unicode character (Victory Hands medium-dark skin tone Emoji).
{
"type": "bitmap",
"file": "minecraft:emojis/v13/u270c-ud83c-udffd.png",
"ascent": 50,
"height": 50,
"chars": [
"\u270C\uD83C\uDFFD"
]
}
Expected result would be to allow this to be rendered as a single character, or allowing the provider to have a json option to render with no gap in between each segment of the emoticon.
Steps to reproduce are to download the provided pack and use the "✌🏽" emoticon in chat.
(note: i set the render size to 50 for visibility)
Unless i'm missing something this will effect most emoticons that use built up modifiers like skintone, gender, option ect. The current workaround is to move these emojis outside of the currently used ranges for the time being so that we can split the modifiers to their own code point until this can get resolved.
Regards
Attachments
Comments 3
I would suspect that this will be marked as invalid as it is really a feature request for support for ligatures
What is actually happening is that the game sees it as two characters, because it is, and so it is texturing the emoji and the modifier separately This is not a bug, as it is still useful to be able to texture the modifier and the emoji separately.
Minecraft currently supports displaying a single code point (often called a "character" colloquially), made of single UTF-16 code units or double UTF-16 code units (surrogate pairs) that will be displayed as a single glyph (the actual image that is displayed)
Minecraft does not support combining multiple code points into a single glyph, referred to as ligatures. Since the game does not support ligatures it is not possible to include emoji with the different skin tones, or other unicode modifiers such as accents on arbitrary characters
The bug is not that it renders with a space, it is actually that it is treating the emoji and the modifier as two separate characters rather than having the skin tone modifier actually modify the character before it
If the same emoji without a skin tone modifier or with a different skin tone modifier were used then it would still render the left half of that emoji character