[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: |
|
||||||||
| Issue Links: |
|
||||||||
| 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. |
| 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 |
| 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 |