Bitmap font inconsistent pixel widths leading to incorrect rendering

[djdanlib]

Hi, I am scratching my head over this one. I think I’ve rejiggered about every setting short of editing glyphs. Raster, raster hinted, changing things in Face Info to integers, different font sizes, exporting the atlas, building new font assets, you name it.

I have this free bitmap font: Silkscreen Font | dafont.com

I’m trying to get a TextMesh Pro UI to display text from that font onscreen. Right now I’m just trying to get the glyphs rendering correctly. It looks like the atlases are sometimes wrong for starters. Here’s one from a 16px version, flipped vertically, inverted, and zoomed in (using Aseprite) so you can see it. Check out the M, N, X, and W.

What I’m noticing in the Unity Editor upon zooming in and overlaying with a 1x1 translucent grid is that certain glyphs are being built with an incorrect width, which alters the character’s subpixel width, which pushes the subsequent characters forward / backward.

The 1 pixel wide ascenders in letters like I and T are sometimes-but-not-always rendering as 2 pixels wide in an 8 px version of the same font. Here’s an example of them being too wide, which messes with positioning.

The texture atlas for them looks fine.

You can see what I mean about the widths in the screenshot below. The characters kind of float around horizontally and it seems to always happen following a chopped character. They don’t float vertically, that is correctly sized.

Here are the Inspectors for the font assets.

So… help! Am I hitting a bug? Am I doing something wrong? Is the font busted?

[Stephan_B]

This “SilkScreen” font is a bitmap font designed at 8 points. Since this is not a scalable font it must therefore be rastered / sampled at 8 points otherwise you will get the issues you are reporting.

Here is an image of a text object using a font asset created using this font.

The above text object point size is 32 which is a multiple of 8 which is the native size of that font.

Here are the settings used to create this font asset.

Again since this is a bitmap font designed at 8 points, we must sample it at 8 points. This font does not support hinting either so we have to use Raster mode.

[djdanlib]

Hey, so that tip about raster vs. hinted raster almost gets me there with glyph rendering, but there’s still a spacing issue. It would be nice to have some way to know whether a font supports hinting or not but that’s maybe a different topic.

This problem exists with the font sampled at 8 points and rendered at 8 points, which is the picture with the blue background below. That’s the game window zoomed in to 5x, not a fractional zoom. Canvas scaler is off, main camera is a plain ortho @ 5 size with no pixel perfect camera script or Cinemachine interfering. I suspect it’s the same issue plaguing it if sampled at 16 pixels (should be straight 2x upsample, no?)

Your font asset creator looks different from mine, too… This is version 3.0.6, I don’t know what you have there but it looks pretty nice.

Here is what I have and what I get.

[Stephan_B]

I think something fishy is going with this font. Ie. I am not sure it is actually designed for 8 points.

When I test other bitmap fonts using Raster or Hinted Raster, they all render correctly at their specified design size but this font doesn’t.

The rastered glyphs in the atlas texture seems fine but the glyph metrics appear incorrect.

If I used Hinted Raster with Sampling Point Size of 8 and then edit the glyph metrics as seen below then a text object at 8 point size renders correctly.

It is possible the X Bearing and Horizontal Advance of the glyphs might also need adjusting.

EDIT: Looks like the Glyph Metric Width (W) needs to be manually adjusted to match the Glyph Rect Width. For some reason, the width coming back from the font at 8 point size is too large for all glyphs.

It could be bad hinting data in the font. So used Hinted Raster and adjust those Glyph Metric Width to match the Glyph Rect Widths.

[djdanlib]

Wow! Thanks for being a font expert, there is no way I would have figured any of that out. Let me know where to leave the glowing review for the support.

This explains why some programs / components render the font differently than others.

It seems like a lot of work to go exhaustively through each glyph and edit parameters until things look correct. If there is a programmatic solution to this I would potentially give it a whack for the sake of curiosity (and future searchers might also be interested) but I’m not THAT invested in using this font.

My takeaway here is: Unless I’m really married to this font (I’m not) then I should find another font that doesn’t have this problem. I have already spent far too many free-time hours on this and the world is hardly lacking for small bitmap fonts.

Again, thanks for figuring it out. I will happily continue using TextMesh Pro knowing that it isn’t the problem here.

Dear future Google searchers, here’s a little SEO to help find this topic: Certain pixel fonts / bitmap fonts might exhibit an aliasing problem, unpredictable as much as it even changes as you change the string being displayed. Aliased text will ruin your attempt at pixel perfect UI text and you’ll spend a lot of your time pulling your hair out when you finally get that font nice and crisp and sharp but it’s still wrong. I guess this is an artifact of using a TrueType font to do a bitmap font’s job. Try other fonts. I hope this thread helps you and that you can avoid wasting as much of your time and the support team’s time as I have on this.

[Stephan_B]

@djdanlib

My takeaway here is: Unless I’m really married to this font (I’m not) then I should find another font that doesn’t have this problem. I have already spent far too many free-time hours on this and the world is hardly lacking for small bitmap fonts.

Since this font doesn’t contain that many characters, it is pretty easy to make the manual edits or just select some other font since you are not married to this one.

@djdanlib

Again, thanks for figuring it out.

Glad I could be of assistance. I will still further investigate this to see if I could detect similar font issues in the future.