Expected behavior:
The game would render characters in the Private Use Area if the appropriate font sheets were present.
Actual behavior:
Even when using a resource pack which assigns these glyphs an appearance, the game does not render them. Inserting these characters is not prevented; the game just fails to render them.
Steps to Reproduce:
1. Create a resource pack
2. Add font files such as "unicode_page_e0.png" or "unicode_page_f8.png" to assets/minecraft/textures/font in your resource pack. These may be duplicates of existing font files, if you wish.
3. Attempt to type these characters in-game, or paste them into a book
4. Observe that, regardless of how the characters appear in your resource pack's image files, the game instead renders blank zero-width characters.
Why this is likely a bug and not intentional behavior:
Note that these characters are no different than other Unicode characters and are well within Minecraft's range of supported unicode (specifically, U+E000..U+F8FF, where Minecraft supports U+0000..U+FFFF). Resource packs can assign appearances to almost all glyphs in the game, apart from these and "forbidden" glyphs.
When a character is "forbidden" in Minecraft (for example, various control characters), it cannot be typed or pasted into books. However, these characters can be typed and pasted; they just fail to render: they aren't "forbidden".
The purpose of the Private Use Area in Unicode is so third parties can add custom characters to their fonts - it would be well within these guidelines for a resource pack or Mojang themselves to add characters here.
If Mojang does not intend for these characters to be used in Minecraft, then they should not be typable in the game. As it stands, by allowing users to input them, but refusing to render them, these characters aren't exactly usable for any purposes aside from censor evasion.
Attachments
Comments 11
Yes, I have done exactly that. I'll attach a resource pack which does this, and a schematic of a command block containing the following text:
"Characters: (End)"
Not even a placeholder renders in Minecraft, whether or not the resource pack is used.
From what I can tell by Grum's comments, the font mcmeta format, which exists in the code, is currently unused? If not, I'll try preparing an mcmeta for the font page.
And while entire pages of unicode aren't restricted, the game does prevent you from typing certain characters directly (§ comes to mind, although this one is interesting in that it can be pasted in books but not typed). Also, newline and return cannot be typed or pasted into command blocks - the game does restrict various characters from use in improper locations.
Found some comments in mcp sources:
ChatAllowedCharacters
/**
* Load the font.txt resource file, that is on UTF-8 format. This file contains the characters that minecraft can
* render Strings on screen.
*/This is in the minecraft.jar (1.6.2.jar) in the root directory:
font.txt
# This file NEEDS to be in UTF-8 format!
!"#$%&'()*+,-./
0123456789:;<=>?
@ABCDEFGHIJKLMNO
PQRSTUVWXYZ[\]^_
'abcdefghijklmno
pqrstuvwxyz{|}~⌂
ÇüéâäàåçêëèïîìÄÅ
ÉæÆôöòûùÿÖÜø£Ø׃
áíóúñѪº¿®¬½¼¡«»That's actually from before Minecraft added Unicode support. Now that it supports Unicode, it's possible to type/paste text in chat, command blocks, and books, without the restrictions of that font.txt.
From what I can tell, ChatAllowedCharacters is still in use for sign text, book titles, and item renaming. Even in these contexts, ChatAllowedCharacters only restricts the characters a vanilla client may input - if an NBTeditor is used to edit in blocked characters, they will actually still render properly.
The blocking of carriage return and linefeed control characters in command blocks doesn't use ChatAllowedCharacters. I'm not sure what it does use, but if you NBTedit these characters in, even they render placeholder graphics ("cr" and "lf", respectively, in dotted squares). From what I've seen thus far, this behavior of "allow the user to type it, but don't render anything" is unique to Private Use characters.
The font directory contains a file named glyph_sizes.bin. This file is an array of 65536 bytes, 1 for each supported character in the unicode range. Each byte contains the starting column in the high nibble, and ending column in the low nibble. If you are creating a custom font, you would need to change the corresponding bytes in this file for those characters to render properly.
Do you have a screenshot to show what you mean by moved to the left? Or is this how you would expect them to look.
I've already found the problem and partial solution in minecraft's decompiled source.
https://mojang.atlassian.net/browse/MC-23952?focusedCommentId=113284#comment-113284
Is this still a concern in the current Minecraft version 1.7.2 / Launcher version 1.3.4 or later? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.
I have been able to confirm Nathan's post regarding glyph_sizes.bin: editing it allows Private Use Unicode characters to render as desired in Minecraft. However, apparently due to the 1.7 resource pack changes, the game now only loads glyph_sizes.bin on startup (MC-41270), and the game will also fail to load private use unicode_page files at any time other than startup. That means it's still a hassle to get these to work (they require a full restart of the client any time the pack is selected or changed, and thus are not compatible with the server.properties resource-pack feature).
At any rate, that's an issue for another ticket, and so this ticket can be closed.
But according to the code there is no restrictrion of any pages. The rendering of characters is simply done graphical.
Did you try to copy an existing working unicode page (like
unicode_page_00.png) tounicode_page_e0.pngto see if the characters are still not rendered ?If the loader cannot check the character width because of broken transparency, the characters are not rendered. Read Grum's comments in MC-17673.