Inaccurate font positioning

[ArenMook]

Does the program you used to export the font have "pixel size" option? Because every single font I export with BMFont exports at exact pixel size. I say I want size 123, it will export size 123 font. Line height and size parameters always match.

[ArenMook]

Exactly as I thought. The problem is in how the font was exported. Here is the real size 64 chalkboard font you sent me, exported from BMFont:

[ArenMook]

Btw, if you look closely, the text in your original font is passing the right side of the box -- something it should never do. That can't be adjusted as there is no "base X". That's what tipped me off that your exported font is busted.

[athos]

If it helps, I'm using GlyphDesigner on a Mac to export fonts. I agree, something looks off in the X dimension as well.

I exported a 64pt font, not a 64px font which I believe is what you've shown on the right. Did you also turn on the match char height option? Maybe that crops the line height down and offsets characters. I don't see an option like that in GlyphDesigner.

In any case, it looks as if there is something in BMFont that is offsetting fonts by the base offset so that it isn't needed for rendering. At the moment, I don't see how else one could ignore the base during rendering and get those results. I suppose that means NGUI right now will only work with BMFont and those settings. Bummer for Mac users.

I understand if you want to leave it at that for now. I'll follow up with the GlyphDesigner author to see if he has a more specific explanation for what we're seeing. Thanks for taking a look.

[ArenMook]

Mac users have 3 choices (or was it 4?) Glyph Designer is just one of them. There is also Hiero and bmGlyph... and one other I'm forgetting.

Windows users like me, only have one choice -- BMFont. I've never heard of anyone having issues with any of those exporting to NGUI, and Glyph Designer was used quite often. Yes, it sounds like you should export with the "match char height" option, assuming it will export the font properly. 64 pt font means jack, to put it bluntly. All fonts have different DPI, so 64 size in one font can be huge, and 64 size in another can be tiny.

Using pixel size is the only proper way to go, and BMFont forces it by default.

[athos]

Yeah, bmGlyph seems to work better with NGUI at the moment.

[mtoivo]

Just to add my own spoon in the soup, as a mac-user. I bought both bmGlyph and GlyphDesigner. At first bmGlyph didn't seem to find all the OTF-fonts in my system, so I ditched it and went with GlyphDesigner instead. Now when I fired bmGlyph again, it seems to find the fonts it missed earlier. Perpahs some reboots or font cache cleanings made it work.

[athos]

It's strange, I must have lucked out at my first attempt with bmGlyph because with other fonts and sizes it renders incorrectly too.

I exported a font at 64px and alignment looked good in NGUI. I used the AutoSD feature to auto-scale down to 32px and 16px fonts and those looked good in NGUI too. Then I tried exporting 16px and 32px versions without doing the AutoSD downscale from 64px so I could maintain separate files and the alignment is off. This time I have space on the bottom instead of the top.

When I compare the two output files, I can see indeed that bmGlyph is exporting different lineHeights depending on whether AutoSD is used to scale down even though they're supposed to be identical pixel dimensions. In any case, the smaller the font I use, the worse the offset problem when rendered in NGUI.

I'm not sure where the problem lies, but so far I've struck out with both of these Mac font export tools. I've been in touch with the GlyphDesigner author though and his new build looks promising.

[71squared]

This is Mike of 71Squared, creators of Glyph Designer. We are looking into this problem at the moment to see what can be done inside Glyph Designer to help address these problems.

It's worth explaining that the font size inside Glyph Designer is specified in font points and not pixels. When GD generates a glyph it uses both the original fonts metrics for spacing and kerning but also calculates new values such as line height. This is because adding stroke and shadows to glyphs can significantly change their size. If the line height is then used to calculate a bounds for a string it will be tool small if those adjustments are not made. Also, the line height as specified by a font at at 16pt is not guaranteed to be exactly double for a font at 32pt depending on the font being used and it's metrics. Using Arial inside BMFont on Windows with sizes 32 and 64 gives a line height of 32 and 63.

Some tools generate SD versions of a font automatically by simply scaling the HD texture atlas and values in the control file. While this means that the line height value is scaled as well, it also leads to odd alignment problems and graphical artefacts. Take a value of 5 for the HD font being scaled down 2x i.e. 2.5. The result will lead to problems when alignment.

I'm looking more closely at how NGUI is using the font data to see if anything can be done in GD to help out. I'm not completely sure how the scaling up from one resolution to another is happening, but certainly expecting the line height to also be in step with fonts that have effects applied will cause problems.

I'll report back when I've got some more information.

Mike

[ArenMook]

Hi Mike, welcome.

The font exported by Glyph Designer that we were looking at didn't have any effects applied. The only problem seemed to be caused by the fact that font size and line height were two completely different values, where in BMFont they always match.

As I mentioned earlier, font size is a misleading number -- it's abstract and varies with every font. It's more correct to go by pixel size instead -- which is what BMFont does. If Glyph Designer followed suit (or at least had an option), I don't think there would be any issues.

[getluky]

Just got caught by this problem. I found out about this because my SD fonts were being positioned in an overlapped fashion in a UIPopupList.

After a lot of elimination of possibilities, I found that my old HD-font prefabs from a previous version of NGUI worked, but re-importing the same bitmap font again through modern NGUI screws up the HD fonts as well. It looks like I'll have to find another font package unless this mismatch of expectations gets resolved. I'll email the GD guys and see if they made any progress since October.

[getluky]

Okay, as another quick update, I exported the same font (Peralta) with Mac Glyph Designer, bmGlyph, and a Hiero.

ALL of them export with a difference between line height and size in the metadata. NONE of them have an option to force these to the same value that I can find.

Fonts exported with any of these tools and imported with the latest (2.2.6c) version of NGUI all get bunched up within UIPopupList even though they display as expected in UILabel.



As you would expect, the SciFi/Fantasy fonts all work fine with UIPopupLists.

As it stands right now, I can't seem to find a way to create fonts on Mac that will work with UIPopupList. I'm not even sure that this is the same issue as in the thread, but it sounds like it. Do you have any suggestions (other than run Windows)?

[ArenMook]

You can increase vertical spacing on the font itself.

[Radazen]

I just ran into this as well. Interestingly, if I revert to GlyphDesigner 1.5.8, I don't have any issues. Any version newer than that and my text starts appearing off-centered and outside of label boundaries. It's a shame, because I'd really like to use the glyph substitution feature from newer versions of GlyphDesigner, but I just end up with a great big mess if I export from anything newer than 1.5.8. I guess I'll start looking at alternatives...bummer, though, because I do like GD a lot.

[getluky]

I had some long testing sessions with the GD author a few months back, and the conclusion that was reached is that this has its origins in the API for font rendering in MacOSX, which only can be accessed via point specifications and not pixels. Apparently on Windows, you can specify pixel size when using the OS to render fonts.

The font rendering pipelines are completely different as well; for bitmap fonts, it may well be the case that "use Windows" to get Cleartype & pixel-based font rendering is the correct solution.

To help a little bit, the GD guy did add in an option for "Default Font Line Height" which he thought might help, but it doesn't completely fix things. One thing that may work is bmGlyph's manual line height adjustment, but it would definitely require some tweaking.