mojira.dev
MC-13046

Certain supported characters glitch out, clearing out lines of text.

Any and all Unicode characters that have transparency at their leftmost pixels (Such as ▗,▝ and ▐) don't work when typed into chat or books: Anything to the right of them is not displayed, allowing players to write "empty" messages on chat and renamed items, and preventing them from using them in ASCII art.
This is NOT an issue of them not being supported: their mirrored versions (▖,▘ and ▌) are properly displayed, and one can find them under "glyph_25.png" in Minecraft's "font" folder.

To reproduce: Copy and paste "▌This Side Works! ▐This one doesn't." or similar in any text field in-game.

Also: *({[*

Fix provided in this comment.

Linked issues

Attachments

Comments

marcono1234

Confirmed for

  • 1.8 The chat stops "responding", so you can't type in any letter

Also with:

KingSupernova

@ Marcono1234

Can't confirm. Are you sure you are experiencing the same bug?

marcono1234

When I paste ▕ in the chat I can't type any more letters (1.8.3)

KingSupernova

Confirmed, but that's probably a different bug.

kumasasa

Cannot confirm in 1.8.3, see screenshot.

KingSupernova

No, he's talking about the "▕" character, not the one in the description. He's also reporting different behavior, which makes me think it's a separate bug.

marcono1234

Confirmed for

  • 1.8.4 based on MC-80169 also for *({[* (only opening ones, might be a problem because of the space in front of these characters)

marcono1234

Confirmed for

  • 15w50a

Could you please update the affected characters?

[Mod] redstonehelper

Did I miss any?

marcono1234

The reason for that seems to be that in glyph_sizes.bin ( for example has a width of 156. I do not know how this is converted however when the game reads the width with the method getCharWidth(char p_78263_1_) of the class /Client/src/net/minecraft/client/gui/FontRenderer.java (MCP 1.8 names) it returns as this.glyphWidth[p_78263_1_] -100 which gets converted to 268435449 as a size.

After some testing I found out that setting the charWidth to glyphWidth[char] & 15 in case it is negative fixes this (but please recheck, I found this out randomly).

renderUnicodeChar(char p_78277_1_, boolean p_78277_2_)

/**
 * Render a single Unicode character at current (posX,posY) location using one of the /font/glyph_XX.png files...
 */
private float renderUnicodeChar(char p_78277_1_, boolean p_78277_2_)
{
	if (this.glyphWidth[p_78277_1_] == 0)
	{
		return 0.0F;
	}
	else
	{        	
		int var3 = p_78277_1_ / 256;
		this.loadGlyphTexture(var3);
		
		//int var4 = this.glyphWidth[p_78277_1_] >>> 4;
		int charWidth = this.glyphWidth[p_78277_1_];
		if (charWidth < 0) charWidth &= 15;
		int var4 = charWidth >>> 4;
		
		//int var5 = this.glyphWidth[p_78277_1_] & 15;
		int var5 = charWidth & 15; 
		float var6 = (float)var4;
		float var7 = (float)(var5 + 1);
		float var8 = (float)(p_78277_1_ % 16 * 16) + var6;
		float var9 = (float)((p_78277_1_ & 255) / 16 * 16);
		
		float var10 = var7 - var6 - 0.02F;
		
		//...
	}
}

getCharWidth(char p_78263_1_)

/**
 * Returns the width of this character as rendered.
 */
public int getCharWidth(char p_78263_1_)
{
	if (p_78263_1_ == 167)
	{
		return -1;
	}
	else if (p_78263_1_ == 32)
	{
		return 4;
	}
	else
	{
		int var2 = "\u00c0\u00c1\u00c2\u00c8\u00ca\u00cb\u00cd\u00d3\u00d4\u00d5\u00da\u00df\u00e3\u00f5\u011f\u0130\u0131\u0152\u0153\u015e\u015f\u0174\u0175\u017e\u0207\u0000\u0000\u0000\u0000\u0000\u0000\u0000 !\"#$%&\'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvwxyz{|}~\u0000\u00c7\u00fc\u00e9\u00e2\u00e4\u00e0\u00e5\u00e7\u00ea\u00eb\u00e8\u00ef\u00ee\u00ec\u00c4\u00c5\u00c9\u00e6\u00c6\u00f4\u00f6\u00f2\u00fb\u00f9\u00ff\u00d6\u00dc\u00f8\u00a3\u00d8\u00d7\u0192\u00e1\u00ed\u00f3\u00fa\u00f1\u00d1\u00aa\u00ba\u00bf\u00ae\u00ac\u00bd\u00bc\u00a1\u00ab\u00bb\u2591\u2592\u2593\u2502\u2524\u2561\u2562\u2556\u2555\u2563\u2551\u2557\u255d\u255c\u255b\u2510\u2514\u2534\u252c\u251c\u2500\u253c\u255e\u255f\u255a\u2554\u2569\u2566\u2560\u2550\u256c\u2567\u2568\u2564\u2565\u2559\u2558\u2552\u2553\u256b\u256a\u2518\u250c\u2588\u2584\u258c\u2590\u2580\u03b1\u03b2\u0393\u03c0\u03a3\u03c3\u03bc\u03c4\u03a6\u0398\u03a9\u03b4\u221e\u2205\u2208\u2229\u2261\u00b1\u2265\u2264\u2320\u2321\u00f7\u2248\u00b0\u2219\u00b7\u221a\u207f\u00b2\u25a0\u0000".indexOf(p_78263_1_);

		if (p_78263_1_ > 0 && var2 != -1 && !this.unicodeFlag)
		{
			return this.charWidth[var2];
		}
		else if (this.glyphWidth[p_78263_1_] != 0)
		{
			//int var3 = this.glyphWidth[p_78263_1_] >>> 4;
			//int var4 = this.glyphWidth[p_78263_1_] & 15;
			
		   int charWidth = this.glyphWidth[p_78263_1_];
		   if (charWidth < 0) charWidth &= 15;
		   int var3 = charWidth >>> 4;
		   int var4 = charWidth & 15;

			// Removed that because of MC-23952
			//if (var4 > 7)
			//{
			//	var4 = 15;
			//	var3 = 0;
			//}

			++var4;
			return (var4 - var3) / 2 + 1;
		}
		else
		{
			return 0;
		}
	}
}
ProfMobius (Thomas Guimbretiere)

Will be fixed in next snapshot (15w51a).

Many thanks for the well written bug report and the accurate solution in the comments.

Cheers!

marcono1234

You are welcome, even though it was kind of random that this worked...
However it is not quite fixed, it looks you might have forgot to change the getCharWidth(char p_78263_1_) method, because when clicking at a long string of these full width characters, the cursor appears at the wrong position. Caused by MC-23952

bugi74

Marcono1234, read my old fix explanation in the MC-7181 (https://bugs.mojang.com/browse/MC-7181?focusedCommentId=54675); it is not that random why the fix works. Unsigned vs. signed integers, sign-extensions, bitshifts...

marcono1234

You are right, thank you for letting me know 🙂

9600 bauds

migrated

Confirmed

book, character, chat, unicode

Minecraft 1.5.1, Minecraft 1.6.2, Minecraft 1.8.4, Minecraft 15w50a

Minecraft 1.7.3, Minecraft 15w51a

Retrieved