[MC-23952] Bad alignment when using wide unicode fonts

When using unicode font with a symbol's width more than 8px, text floats to the left.

How to reproduce:

Take a resource pack from attachments.
Select the resource pack in the game.
Restart the game.
Change language to Pirate Speak, French, etc.

Linked issues

is duplicated by 2

MC-64756 The letter "ğ" Resolved

MC-70915 Alignment bug when using wide (>7px) glyphs in unicode font Resolved

Attachments

azz.class

widefontbug.zip

Comments 27

Erik Broes 2013-07-11T11:58:13Z

I think you need to work harder to reverse engineer the glyph_sizes.bin.

rumickon 2013-07-11T18:16:09Z

Thanks for reply Grum.
Ok. When I am using another font with a symbol's width 8px or less it looks good (screenshot 06). But if symbol's width is 10px (screenshot 07) then text floats to the left. I edit the file manually by hex-editor. What do I do wrong?
P.S. Same problem width default font and Hindi language (screenshot 08).

Jumpin Carrot 2013-07-29T19:09:00Z

rumickon, Did you figure out how to fix this? I'm trying to solve the same problem with no luck.

rumickon 2013-07-29T22:16:23Z

Test with this patch: https://www.dropbox.com/s/bkltsmz6o65zcwk/alignment.zip (for 1.6.2)

Jumpin Carrot 2013-07-29T22:48:53Z

Wow, that helped. Thank you very much.

17 more comments

Reality_SC 2013-10-21T11:43:13Z

I confirm the problem in 13w42b.

Reality_SC 2013-10-21T12:20:52Z

The only way to make it working is decompile .jar, find FontRenderer.java and comment this condition lines:
...
} else if (this.glyphWidth[ symbol ] != 0) {
int start = this.glyphWidth[ symbol ] >>> 4;
int stop = this.glyphWidth[ symbol ] & 15;
/* HERE:
if(stop > 7) { stop = 15; start = 0; }
*/
stop += 1;
return (stop - start) / 2 + 1;
} else {
...

I don't understand the aims of this condition.

rumickon 2013-10-21T15:03:56Z

Fix for 13w42b: azz.class in attachments.

Reality_SC 2013-10-22T04:14:13Z

I think Mojang should patch this cause this is a bug.
We can create patches for every version but this is not right way.

Jumpin Carrot 2013-10-22T13:11:44Z

Mojang doesn't want to fix this. It's marked as resolved and "Works As Intended". They just don't care.

marcono1234 2015-01-20T15:26:22Z

Why is this "Works As Intended" now?

Dlawso the Really Lucky Rabbit 2015-01-20T15:47:36Z

Marcono and Jumpin Carrot, from the words of Grum:

I think you need to work harder to reverse engineer the glyph_sizes.bin.

Resolution Works As Intended [ 6 ]
Status Open [ 1 ] Resolved [ 5 ]

marcono1234 2015-01-20T16:06:46Z

Nice ...

Reality_SC 2015-01-20T17:13:39Z

Can @rumickon reopen it? It does not works as should. To fix it in code @Grum should remove just one simple construction in "FontRenderer.java".

rumickon 2015-01-20T17:38:16Z

No, I can't. But we have another bug: MC-27912 with same problem.

Jumpin Carrot 2015-01-20T20:00:47Z

But it's not just Hindi, wide variety of unicode fonts are affected. The main problem is in the fonts: many fonts are too thin and mismatch overall style of Minecraft, also they are hard to read. If anyone tryes to fix this with resource pack\custom fonts, they are faced with the need to change widths in glyph_sizes.bin And if you do so, all text becomes misaligned.
This makes this problem unsolvable! The only way left is to decompile FontRenderer.java for each version of Minecraft.

Christie N 2015-01-20T20:01:37Z

The intention with the unicode font seems to be to have a variable-halfwidth font (for Latin/Greek/etc.) and a fixed-fullwidth font (for CJK/etc.). However, the glyph_sizes.bin file doesn't reflect this, with regular points reading 1e, and others ending in -a, -b, or -c. This is causing the distortion. Every fullwidth character in the glyph_sizes.bin should be of width 0f.

Note that the Unicode font (GNU Unifont) is a fixed-width font.

Reality_SC 2015-01-21T03:43:17Z

Recently I found fixing solution that is appropriate for me. For not to decompile client just 1. Find .class containing "glyph_sizes.bin" string in bytecode — there always be only one file for any minecraft version (made from FontRenderer.java). 2. Find the bytes 10 07 A4 and replace them with 10 0F A4 with your favorite hex editor. These bytes are the code for "if(charWidth > 7)" so here we change it to "if(charWidth > 15)" that is never true. Working with Optifine bytecode too.

rumickon 2015-01-21T05:07:38Z

@Reality_SC yep. Change one bit only.

Christie N 2015-01-21T21:01:29Z

Probably related, Minecraft has no support for combining diacritics, so why are they even allowed past Crowdin?

rumickon 2015-11-20T20:12:34Z

Reopen please

Dlawso the Really Lucky Rabbit 2015-11-20T21:03:52Z

Likely 0% chance of reopening because a Mojang employee resolved it as intended.

rumickon 2015-11-20T22:15:57Z

Also, this problem was solved in Forge after that commit: https://github.com/MinecraftForge/MinecraftForge/pull/1804
Its very easy to fix. Why Mojang employees ignore it, I do not understand.

marcono1234 2015-12-13T14:56:20Z

Confirmed for

15w50a based on MC-27912

This is definitely valid, like @unknown said already in his comment these lines mess everything up. For example they return for both ① (\u2460) and ╬ (\u256c) the same size (force unicode is off) even though when writing one line of ① and below it one line of ╬ you will see that they have not the same size.
This is in the method getCharWidth(char p_78263_1_) of the class /Client/src/net/minecraft/client/gui/FontRenderer.java (MCP 1.8 names).

if (var4 > 7)
{
	var4 = 15;
	var3 = 0;
}

marcono1234 2015-12-13T21:51:33Z

Can you please include this?

[Mod] redstonehelper 2015-12-13T22:40:02Z

The ticket is resolved anyway. If they choose to look at it again they will see your comment.

marcono1234 2015-12-17T16:28:49Z

Confirmed for

15w51a

Bugs that are caused by this:

MC-13046 (only that clicking on the character in the chat line places the cursor at the wrong position)
MC-52937
MC-80169