Custom fonts do not display properly

Yes, the character widths are all over the place. The o, f, and s are way too wide for example, and the i is too narrow.

This happens also for non-HD (128x128px) custom fonts. It seems the spacing for the original "default.png" is used.

It uses the 'kerning' of the default font. Not something we can fix easily as the widths are ints right now.

Will eventually get fixed! 😃

Yes please, would be great if fixed soon. 🙂
This means that most texture pack authors will have to remove their custom fonts until then.

Yes, please consider changing all the character and string width calculations to floats. That is essentially what MCPatcher's HD Font patch does now, and I'd like to remove that patch altogether someday.

Don't forget to add a default.properties into the /fonts/ folder. That way we can specify character spacing if the game gets it wrong. for example.

1. width.<ascii value="" 0-255="">=<width 0-8="">

width.42=4

width.72=5.25
width.81=5.25
width.82=4.5
width.88=5.875
width.89=6.125
width.108=3.875
width.111=4.1
width.113=5.75
width.120=4.75

This is my custom font. As you can see, the spacing is crazy.

I should perhaps remind you guys that we're not ever looking at mcpatcher for inspiration.

Maybe you should be. mcpatcher works.

Nonetheless, it still needs a way to change the kerning, whether it be automatic or manual.

@Grum Why on Earth not? It's been the standard for the formatting of high resolution texture packs since long before Minecraft even had basic support for low resolution texture packs. By ignoring it completely, you're only really doing a great disservice to the countless texture pack artists who have poured (literally) years of effort into their texture packs.

Also if I'm not mistaken, Mojang appropriated MrMessiah's Better Light mod (SSAO/Smooth Lighting) over two years ago because of the exposure it gained through MCPatcher's distribution. I've been a part of this community since before the concept of a texture pack even existed, and had it not been for MCPatcher, they likely wouldn't have reached the categorical status they currently have. To ignore the impact MCPatcher's had on the community and early development of the game is to embrace or profess ignorance of the subject.

Now my opinion on Mojang not looking at MCPatcher for inspiration on how to fix things is totally up to the coder/Mojangster who is trying to fix/implement the feature in question. But @misa has a point & plus using @Kahr 's MCPatcher's method of changing width calculations to floats can be a quick fix you guys can do, & then come back later to fix the feature the way you guys(Mojangster) want it to be.

This is just my opinion, & it's totally up to Grum to do this how he wants it to do it, whether that is use MCPatcher's way of doing it or another way, that's totally up to him to decide

@Grum:
You can't expect everyone to like the vanilla font, so you should at least give us a way to properly change it. Just telling us "Will eventually get fixed!" sounds a bit careless (I mean, it's your job to fix and improve things, or not? And there's already a good fix out there, so it's a win-win for you AND the community 🙂).

@Mark Cashion:
Yes, it's up to the coder to fix/not fix it, but arbitrary decisions don't make Minecraft a better game (and the purpose of updates is to make it even better, or not?). So the one and only question is: Is there a way to do it better than MCPatcher? If so, do it better Mojang! If not, I see no reason to not include that part of the Patcher to vanilla Minecraft.

So they decided to add Custom and HD fonts (which is a great feature btw.). What did they do exactly?
They did the same as with (nearly) every new feature:
1.) Throw in the feature
2.) Let the community test if it works
3.) Fix or not fix any bugs
4.) Maybe looking out for a method to do it better afterwards

THIS is what they should do with every new feature:
1.) Search for a mod which already does it
2.) Check if there is a better way to do it
3.) If not, include the mod to vanilla Minecraft
4.) Everyone's happy 🙂

While the ability to read the font file in texture packs is nice, the font file will remain unusable until font kerning is corrected. I am removing the /font/default.png from Soartex until the texture can display properly.

I hope the bug fix introduced by MCPatcher doesn't prevent the bug from being fixed via changing the data type, if fixing the bug via changing the data type is the best way to solve the bug.

We didn't add support for HD fonts? We just added away to load the font-images from the texturepack files rather than exclusively from our jar.

The code to load supports any size of texture but it will not properly poll the widths of bigger textures. I think currently it doesn't even update the widths table after the initial load.

We noticed ourselves that there were some issues with the higher resolution fonts but fixing it properly would not be possible before 1.5.

We'll eventually add support for higher resolution files, so expect to see more texturepack changes for 1.6 (or later).

Ideally, the best solution should be applied to a problem. Looking at existing solutions before attempting to solve the problem yourself can be harmful, because it shifts your perspective from thinking about the problem to thinking about that specific solution. It can deter you from discovering a better one that is fundamentally different.

Also, implementing a bad solution to a problem can lead to a good solution never being implemented – people get used to dealing with the bad solution, and are resistant to change, even if it's for the better. Sometimes it's better to take a little extra time, and do something right the first time.

@Grum:
OK, thanks. Looking forward to see more texturepack changes 🙂

@Torabi Anything has a chance to be harmful if handled incorrectly. However, it'd be counter-productive to take an approach that is less likely to produce positive results. Limiting one's exposure to other options and viewpoints often does more harm than good. Major advances are rarely non-derivative from pre-existing sets of work. (Science, anyone?) They may still be a completely different approach in the end, but the pre-existing bodies of work may also show them what's been tried with positive results and may give them ideas for what approaches to and not to pursue when coming up with a new and better solution.

Sure you can get lucky by keeping your line of work in a bubble and ignoring all external viewpoints, but a 'bigger-picture' approach with inductive reasoning shows that it's not probable enough to be a practical approach. Pragmatically-speaking you should adopt what works best and be open to immediately dropping it once a better solution is found. Saying you should avoid working-approaches because it might taint how you approach an issue can easily imply that the developer is too impressionable and close-minded to think outside of the box and/or is incapable of learning from the success and mistakes of others. (Or to be fair, against all odds, they're some kind of übermensch. 😛)

The grammar you used leads me to believe that you're fully aware that this is a probabilistic argument. I also applaud you for honestly avoiding absolutes (So rare in arguments on Internet communities. 🙂). I just believe that for the sake of the most ideal solution, you may be arguing for the side with a lower chance of success.

Thanks for the update Grum!

@misa: I'm not saying that it's best to avoid all input or existing solutions, but that there can be hazards to jumping immediately to existing solutions without spending some time thinking about the problem yourself. You risk getting trapped in local optima, because you are skipping part of the creative process. That doesn't mean you can't come back to it, but you're less likely to do so, both because your problem is partially solved (though not necessarily optimal).

There are many possible strategies, and it's probably best to include both research on previous attempts and existing solutions (to take advantage of that which has been done by others), as well as personal research (so as to take advantage of whatever unusual traits you may possess that would provide new insight to the problem). The question of how much time and effort to spend on each strategy, as well as what order to execute them, will depend on the individual.

I'm primarily arguing against the demand that existing solutions be accepted and implemented without thought or analysis – here specifically that an innovator in a field should stop innovating and just do what someone else has already done, because that's what people are used to. Mojang may end up solving this particular problem exactly the way MCPatcher does – but it should be because they determine it to be the best solution, not because of any historical reason. Concessions to history generally end up being harmful long after anyone can remember why they were made.

@Torabi There are always hazards, but in this case, the benifits outweigh the hazards. Grum has already stated in no uncertain terms that they will never look at MCPatcher for inspiration. I'd say that safely precludes them coming back to it to compare their work to it after the fact. It also displayed his ignorance on the subject as Mojang has in fact successfully looked to MCPatcher for inspiration in the past (Before he was even a part of Mojang).

Them taking time to work on their own solution without influence (ultimately leading to the better chance of reaching the best solution) would still require adoption of the premise that Mojang is competent enough to do so. I personally don't have that much faith in them. Though to be fair, I also don't think they're completely impressionable or incompetent that they'd fail to benefit from even looking at MCPatcher. I do think it can be pretty easily demonstrated through simple observation of their recent actions on texture packs and the rendering engine, that their implementations of existing features in MCPatcher are woefully inadequate (in the areas of optimization, performance, user-friendliness, and versatility) by comparison. However it can't be blamed on any one person—and therein lies some of the problem. They lack a proper division of labor structure that the vast majority of successful development teams adopt. All of them seem to come from a similar background in programming and are doing too many jobs at once that aren't normally best-suited to programmers (Notch was sort of a rare exception and even he had some problems). Their lack of a more specialized organization has led to many seemingly-forgotten, half-implemented features; a steady decrease in game performance; and a decrease the implementation of accessible content over time.

By contrast, MCPatcher's developers have been dedicated to specializing in solving a single issue for longer than the current Mojang team has even been employed. It works with and around the development of the main design team—improving upon some of their faults while avoiding encroaching too much into territory beyond the scope of its intended design. It has had multiple authors and expert consultants responsible for its development. It has also undergone many format revisions and re-writes to adapt to major changes in the game which have always ultimately optimized its own performance, user-friendliness, and versatility.

Now, I'm not arguing that MCPatcher should be accepted or implemented without any thought or analysis. I'm simply arguing that based on its merits, it shouldn't be outright rejected and ignored without any valid justification as Grum has done. Even if they had taken a practical approach with MCPatcher, I would not see it as a concession to history so much as consultation of those who (at this point) have demonstrated the greater likelihood of currently being the genuine experts on the subject. By closing the doors without much thought or justification they are insulating their development process and decreasing the chances of a good self-correcting system of development.

Confirmed for 13w11a!

Still affects the 1.5.1 pre-release!

Still not fixed in 13w16a !

Aaand still no fix for this in 1.5.2 and 13w17a !

If the devs can't fix this bug by now, then apparently they're not competent enough to run the development of Minecraft and should give the dev duties to other, more ept, programmers.

On the contrary, why not have two integers for the font width - one for each character, representing the width in pixels, and the other dictating how many pixels each character box takes (8 for default, 16 for twice the resolution, 32 for four times, etc.)?

The order in which bugs are addressed is influenced by the number of votes on the issue here on the Mojira. There are currently 15 votes for this issue, which isn't even enough to get it on the Popular Issues page. If they had concentrated on fixing this bug, they probably could have by now. However, there are 1500 other unresolved issues all demanding their attention, 65 of which have more votes than this one.

This will eventually get fixed, but it's just not a high priority right now.

Ah, I see. I just thought that it was important because it was a fundamental bug with the font renderer.

Torabi is absolutely right. Upvote this bug, everyone, upvote ! ... 🙂

Still waiting for a fix ... 13w18a 😞
EDIT: Same with 13w18b and 13w18c

C'mon, Mojang, still no fix for this in 13w19a?

And it still has only 16 votes, and there are still a ton of other unresolved issues (the recent snapshots have introduced a lot of new bugs). This is a minor issue that most people are not affected by. How do you expect it to compete with bugs that destroy people's worlds or prevent them from playing at all?

@Torabi:
I had absolutely no crash problems with any 1.5 or 1.6 snapshots, but I always find the same bunch of old visual problems which should have been fixed versions ago. You don't think they have some kind of priority, especially for people working with textures or playing with texturepacks?

No fix in 13w21a/b !

Actually there is just no support for having a Font that is not aligned with the locations in the current font metadata.

Make it align with that and suddenly there are no issues.

Obviously that leads to some restrictions but there is no claiming 'it cannot be done'.

That said to fix this issue properly we need to do quite a lot of other fixes in different areas (rendering of the fonts (mostly related to width-calculation) and removal of the static and dynamic calculations we do at this moment). This is something we'll hopefully finish for this snapshot, we might not however (as it also requires more drastic/major changes in how we do metadata in resourcepacks).

Also: @Misa, just for clarification:

I should perhaps remind you guys that we're not ever looking at mcpatcher for inspiration.

People claim we implement MCPatcher's features and then do a half-assed job mimicking them. We do not look at any other external mods when we do these features, we're not trying to 'replace' them, be better or be worse than them. We're just adding things that we think should be possible right now and that are in the scope (both idea and implementation time-wise) at that moment.

I dare say we've ended up with a better HD implementation for item/block-textures than anything else sofar, something future compatible with plugins as well.