[MC-7181] UTF-8 char locks Textbox Created: 11/Jan/13  Updated: 03/May/17  Resolved: 17/Dec/15

Status: Resolved
Project: Minecraft: Java Edition
Component/s: None
Affects Version/s: Minecraft 1.4.7, Minecraft 1.5, Minecraft 1.5.1, Minecraft 1.6.1, Minecraft 1.6.2, Minecraft 13w37a, Minecraft 1.7.4, Minecraft 14w05b, Minecraft 14w06b, Minecraft 14w07a, Minecraft 14w08a, Minecraft 1.7.5, Minecraft 14w18b, Minecraft 1.8.1-pre3
Fix Version/s: None

Type: Bug
Reporter: Kevin Gut Assignee: Unassigned
Resolution: Duplicate Votes: 1
Labels: None
Environment:

Windows 7 x64; jre 1.7


Attachments: JPEG File UTF-8-Compatible.jpg     JPEG File UTF-8.jpg    
Issue Links:
Duplicate
duplicates MC-13046 Certain supported characters glitch ... Resolved
CHK:
Confirmation Status: Community Consensus

 Description   

Pasting the char ( in any Textbox will make Text after it invisible. If you set it as World Name you still can use the world, but the Text in the Box is missing. This makes Worlds without Names possible.
Please note, that the char is not an open parenthese and you need to copy-paste it. The Directory created for the world contains this char and looks regular.



 Comments   
Comment by Markku [ 17/Dec/15 ]

Original descriptions are somewhat different, but indeed, the same cause (incorrectly calculated widths) is behind these issues. So yes, a duplicate. (Marcono and I even found the same fix independently.)

Comment by Marcono1234 [ 17/Dec/15 ]

Duplicates MC-13046

Comment by Galaxy_2Alex [ 25/Oct/14 ]

Reopened, thanks

Comment by Kevin Gut [ 25/Oct/14 ]

Yes it is still a concern with the newest version

Comment by Itouch2 [ 06/May/14 ]

Confirmed for 14w18b.

Comment by Itouch2 [ 28/Feb/14 ]

Still affects 1.7.4/5 and 1.8

Comment by Galaxy_2Alex [ 22/Jan/14 ]

Is this still a concern in the current Minecraft version 1.7.4 / Launcher version 1.3.8 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.

Comment by Markku [ 10/Jul/13 ]

Still in 1.6.2

Comment by [Mod] Ezekiel (ezfe) [ 10/Jul/13 ]

Is this still a concern in the current Minecraft version? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.

Comment by Kevin Gut [ 01/Jul/13 ]

Updated the issue, still present in 1.6.1

Comment by Markku [ 27/Mar/13 ]

Kevin, I recommend reading my analysis more carefully, or alternately, reading Java language specification. Basically, Java does not have unsigned integer values. The only exception is 'char', which is basically unsigned 16-bit integer with a little bit of unicode related sugar. Unfortunately, as soon as any kind of math/bit-operation is done with such value, it is implicitly converted into 32-bit signed ints, and all kinds of headaches and keyboard throwing contests ensue.

But yes, using such unsigned integer value would have done the trick.

Comment by Kevin Gut [ 27/Mar/13 ]

instead of int it would be better to use an unsigned int. wouldn't this solve the problem?

Comment by Markku [ 17/Mar/13 ]

Fix

FontRenderer.renderUnicodeChar(char c, boolean italic)
        ...
        //int startColumn = this.glyphWidth[c] >>> 4;
        int startColumn = (this.glyphWidth[c] >>> 4) & 15; // FIX
        ...

Tested on 1.4.7, works wonders.

Reason was that the byte for 'glyph width' is handled as unsigned value, whereas Java only does stuff as signed values (except 'char' of course) and bit-operations in 32-bit things. Before doing the bitshift (which does have the nice >>> op), it will sign-extend the byte. If the high nibble has large enough value (8..15), it basically means the byte has negative value, and thus the 32-bit integer being shifted is also negative and has 24 extra 1-bits on left. After the shift, such integer value converts into a very large positive value. The start column was thus calculated to be a very, very, very large thing, causing multiple problems, like rendered width to be millions of pixels. (The rest of text was thus way past the visible area.)

For that particular character used in the description: its codepoint is 65288, glyph width value -100 (or nibbles 9 and 12), and the shifted result for start column 268435449!

Comment by Kevin Gut [ 17/Mar/13 ]

Version 1.5 is still affected

Comment by Kevin Gut [ 11/Jan/13 ]

Textboxexes seem to accept most UTF-8 chars.

Comment by Kevin Gut [ 11/Jan/13 ]

Example of an empty name due to UTF-8 Bug

Generated at Sun Jan 12 12:13:39 UTC 2025 using Jira 9.12.2#9120002-sha1:301bf498dd45d800842af0b84230f1bb58606c13.