Minecraft seem to use the glyphs from code page 437 (aka CP437, OEM 437, PC-8, MS-DOS Latin US) for its default font. Wikipedia says that when using this code page the German sharp s (ß) should share the code point (and therefore also the glyph) with the Greek beta (Hex: DF / Decimal: 225).
However, Minecraft does't do that as you can see on the screenshot incorrect-german-sharp-s-in-chat.png. As it uses the unicode font renderer, the German sharp s (ß) is displayed way too small. By comparing the screenshot to what your browser will display in a monospaced font, you'll see the difference more clearly:
schließlich
The file default.png you can find in minecraft.jar/font contains a Greek beta glyph. The beta glyph looks a bit too bold but I'm sure that it would still look better when using that one for the German sharp s than it currently does. (See minecraft-default-font-characters-with-highlighted-german-sharp-s.png.)
—
Some additional background information about the German sharp s: The ß glyph can be considered somewhat of a normal letter in the German language. It is used very often. Therefor by displaying the German sharp s way smaller than other letters, a visual break in chat appears quite often - which is an unnessesary annoyance that could be fixed easily. (By the way: The other normal German non-ASCII glyphs öäüÖÄÜ work as expected in Minecraft as the code page 437 is applied properly there - it's just the ß.)
Linked issues
Attachments
Comments 7
MC-8353 describes a more general problem: the letter size difference between unicode letters and Minecraft's default font set letters. I'm not trying to adress this general problem here though. So MC-8353 is related to this but not a duplicate.
This ticket simply adresses the fact that even though there is a ß-like glyph in Minecraft's default font set which - going by the norm of code page 437 (that is used by Minecraft's default font set) - should be used for the German sharp s, it is currently not used for that.
—
To put it differently: It is true that Minecraft's unicode rendering engine kicks when using most non-ASCII letters (note: ASCII doesn't contain äöü etc. and is therefore different from code page 437). However, it is also true that it does not kick in for most characters in "minecraft.jar/font/default.png" (whose contents you can see in minecraft-default-font-characters-with-highlighted-german-sharp-s.png). From what I understand by looking at the code page 437 norm, the unicode rendering engine should not kick in for the German sharp s as well (currently the unicode rendering engine also kicks in for it); the Greek beta glyph from "minecraft.jar/font/default.png" should be used instead.
—
And just a short clarification for all glyph experts: I know that using the Greek beta glyph to display the German sharp s is usually wrong since both characters are not the same (although pretty similar to each other). However, as Minecraft uses a very low-resolution bitmap font, the difference can not really be seen. Using the Greek beta glyph here would make text simply be displayed more homogeneous. (This is also the reason why code page 437 didn't introduce an own glyph for the German sharp s - both glyphs looked similar enough for contexts in which that code page came to use. And this is also true for Minecraft.)
(I'll happily bypass the issue how weirdly the Minecraft font rendering decides which way it works or which glyph set to use... that would be another issue.)
If the MC-8353 will be "fixed" (i.e. those letters that look small in there would look similar size as other text; and note that german letter in this issue would be part of those letters, too), this issue would get fixed along. Assuming the problem is simply how small that letter looks.
So yes, this would be duplicate. (Edit: just to clarify; an issue that is a subset/sub-problem of another issue is a duplicate of that another issue.)
Also, coding "exceptions" to normal logic rules is very bad programming practice, especially when that exception is against the expected standard behavior, and leads to future maintenance problems and bugs. Think it like this: what if in future the font rendering is otherwise for full unicode. Suddenly everything else looks good, except that german sharp s will be shown as silly blocky beta. Yet another bug that could have been avoided.
The rule of thumb is: do not fix the symptom (with incorrect behavior), fix the cause.
I agree with most of what you say, with following two important exceptions:
First, even though this might be considered an exception to a logic rule, it actually is a pretty clear violation of a specification: From what I understand, the spec for code page 437 actually tells you to use the Greek beta symbol for the German sharp s. So the exception should actually be the rule in this case. And in Minecraft the rule is currently not implemented as it is defined in the spec. Therefore the current behavior is still wrong.
Second, if you tried to apply the "do not fix the symptom, fix the cause" way of doing stuff to every single issue, you wouldn't get very far. The amount of time and costs to fix something has always be balanced out with the benefits. Sometimes a smaller fix that doesn't deal correctly with every single issue already helps much more than a fix that tries to be all-encompassing.
To apply this balancing to this issue: The code for handling some special characters differently (äöüé etc.) is already there. Simply adding another code line to handle the ß according to the spec would result pretty much no work. However, it enhances the appearance of normal German sentences with ß at lot.
Minecraft is not trying to implement code page 437 specification. It is trying to implement Unicode, with some twists for cp437 characters. And unicode specification has no obligations (not even recommends) to show the same glyph for both of those characters. (Minecraft did start with the cp437 glyph set, but luckily that is now history). So, there is no "violation of a specification" going on.
I do not propose to apply the "do not fix the symptom, fix the cause" to every single issue, but this particular issue is one where the rule fits the case perfectly. There is already a problem with the current implementation (which is doing something like you want here, but in a larger scale), and the change you're asking is only making that problem larger; it will not "help much more" but "makes it even worse". As I already told, fixing the other, larger issue would fix both this and that other one.
The code that handles some characters differently (namely, most of the ones in cp437, not just äöü etc.) is indeed in there, but it does not work like you seem to think. And the code should not be there at all; there is no need for it. (It is just to get the old font conveniently for some characters).
Note also, it might be possible to simply adjust that glyph in the unicode set. With latest changes, this can be done by players (like texture packs). No code changes needed.
Okay, I just fired up MCP to see what you mean. And I do understand now that applying a fix for this wouldn't be as easy as I assumed it to be. So this actually does need a "larger" fix. :-/
(I assumed that there was some kind of simple lookup switch-statement that maps some Unicode characters to X/Y coordinates on the default.png font image. Something like this actually exists in form of the font.txt - however, you would have to add several of those cp437 characters there to make it actually work for the German sharp s. And that feels way more dirty than it currently is.)
If a mod happens to stumble upon this, you can close it as a duplicate of MC-8353 - after seeing the code I agree with you that this resolution makes most sense for this ticket.
Moderators, read previous comment; considered duplicate of MC-8353 (by all=both involved).
Probably a duplicate of MC-8353.
The bug is not that Minecraft is not using that default glyph set for that german letter; when doing things in unicode (as Minecraft mostly seems to do), using that greek beta glyph would be a bug. (It is only a recommendation when no other font/glyph set is available).
The real problem is likely that the some glyph sets look different than others.