Hi, if you have solved this, please mark your post as the solution so that people know it is solved, and if you can, raise a bug report on the GitHub pages, thanks.
Happy Coding!
Hi, if you have solved this, please mark your post as the solution so that people know it is solved, and if you can, raise a bug report on the GitHub pages, thanks.
Happy Coding!
It would seem that this change introduced a regression with kerning: Optimized SpriteFont GlyphPacker by TechPizzaDev · Pull Request #7464 · MonoGame/MonoGame · GitHub
I haven’t verified but leaving this here in case anyone wishes to investigate.
Is there a way to workaround this for now without downgrading MG from 3.8.1 (i.e. a way to use content/fonts built with 3.8.0.1641 in 3.8.1.303)? This kerning issue is kind of a big deal for our new title and I don’t have the font knowledge/expertise to fix this in MG’s font processor myself.
I don’t know if I have polluted MGCB installs or something, but I cannot reproduce this kerning bug.
I get the expected good-looking result on both of the given configurations.
Here’s a sample project that demonstrates the issue:
If you run it, it will open 2 windows on top of each other. Drag 1 window out of the way and you should be able to see the differences. The only difference between the 2 projects is 1 references package MonoGame.Content.Builder.Task 3.8.0.1641, and the other references package MonoGame.Content.Builder.Task 3.8.1.303
I built one project with 3.8.0.1641 (MGCB and MG in Visual Studio 2019) and one with 3.8.1.303 (MGCB and MG in Visual Studio 2022) and got these results:
Identical SpriteFont file in both environments; referencing Arial at size 50 and built using Color TextureFormat instead of Compressed
To my surprise, when I tried to use the built SpriteFont xnb from 3.8.0 in my 3.8.1 build, it seemed to just work. I had thought in the past I got an error when attempting to do this saying the content was built with the wrong version of MGCB.
I found the culprit:
Commenting this additional code out brings back the old layout. This change was allegedly a fix to some issue, so I feel like this current solution is not correct.
At least it was not my glyph packing PR
Your glyph packing was fine.
But I stand by my PR.
MonoGame does not implement kerning. The spacing between letters in MonoGame’s SpriteFont is based on the horizontal advance in TrueType fonts which is letter spacing.
For MonoGame to implement true kerning, spacing between individual letter pairs needs to be stored in the xnb and rendered in SpriteBatch.DrawString
After updating to 3.8.1 I see incorrect kerning (similar to your example).
I have to use xnb font files generated by 3.8.0 - otherwise text does not look good.
We do this as well because of how odd the spacing is when building fonts in 3.8.1
@nkast I am unfamiliar with the font processing process, but I’d be interested to know why you “stand by” your PR? Is it simply mathematically more correct or some such? I think if it was visually correct, we wouldn’t have so many people noticing/questioning it. Not to mention circumventing it entirely like myself and @Powered_JJ.
The change fixes the values that are written in the "kerning’ field of the glyph. The code now produces values that are closer to the letter spacing of the character.
That is what you would get from win32 GetCharABCWidthsA() method for example.
I would say, it made one part of the equation ‘Symantically’ correct.
Mathematically you can often have two wrongs equalling one right
Fair enough. Not that I get a say, but I would vote given that info, this fix should instead be placed in a comment so it can be applied when the “other end of the equation” is also fixed. Because I understand you’ve fixed one part of it to be technically correct, but as it stands the end product has more noticeably messed up spacing than what we were working with in 3.8.0. Thus, why I and apparently others manage a completely separate MGCB for compiling SpriteFonts.
For the record, I (and presumably others) very much appreciate your efforts to make SpriteFonts better! Just right now this particular update seems sorta half-baked and yet still implemented into stable MG, which is causing some of us some minor headaches, is all.
The other issue started manifesting after #7501 was applied.
Hindsight is 20/20, the only thing you can do is to address one issue at the time,
and then move on to the next. If you are going back and forth, you would find your self standing still.
The issue you are seen has to do with the glyph cropping, not the kerning data.
The processor writes 0 while it should write the XOffset (plus FontBitmapLeft which is kinda part of cropping).
Whatever the cause, the end result looks bad.
3.8.1 produces text, that just looks wrong - not fit for a polished, final product of a game.
I appreciate the efforts to make MonoGame better. But this change should not make its way into stable branch. MonoGame is a great framework and I hope this issue will get resolved soon.
Does someone know if there’s a way to replace xnb font files when building for Android?
For any platform, I open my .mgcb with a copy of MGCB v3.8.0.1641, set the target platform at the root level, then compile only my SpriteFonts.
Seriously. This kerning looks sooo wrong…
Agreed. The difference is very noticeable with the fonts I’m using (Arial). I hope this issue is prioritized and fixed soon since text-rendering affects so much of almost any game. I’m still intentionally using an outdated build of MonoGame.Content.Builder.Task just to avoid this problem.