Major Issues with Custom Fonts after latest Device FW-Updates

I need to discuss this with someone more familiar with the font system, but I believe I have found the root cause as well as the code generating the error that was previously ignored. The issue appears to be caused by a check for invalid font values when loading the font. This system error seems to be limited to the fr645m at this time.

When parsing the .fnt file, the base height is the value of the 'base' attribute from the 'common' line. The digit height is initially set to the base height, but if glyph 48 (character '0') is present, then the height of that glyph is used as the digit height. If the digit height is larger than the base height, then a negative value is generated for the internal leading vertical space, and a system error is generated.

As far as I can tell, this is actually an invalid .fnt configuration that is only possible when using hand-edited .fnt files.

Given this, you should be able to work around the problem by ensuring that the digit height is always less than or equal to the base height.

Thank you so much for this explanation. I'll try this out tonight and get some users test this. That would be an easier workaround than I currently have. Thanks!

Hi Travis,

even if heights are fully equal, I've the issue. Example:

info face="Arial" size=32 bold=0 italic=0 charset="" unicode=1 stretchH=100 smooth=1 aa=1 padding=0,0,0,0 spacing=1,1 outline=0
common lineHeight=32 base=26 scaleW=256 scaleH=256 pages=1 packed=0 alphaChnl=4 redChnl=0 greenChnl=0 blueChnl=0
page id=0 file="Moon2_0.png"
chars count=9
char id=48   x=0     y=0     width=32    height=32    xoffset=0     yoffset=0     xadvance=32    page=0  chnl=15
char id=49   x=33    y=0     width=32    height=32    xoffset=0     yoffset=0     xadvance=32    page=0  chnl=15
char id=50   x=66    y=0     width=32    height=32    xoffset=0     yoffset=0     xadvance=32    page=0  chnl=15
char id=51   x=99    y=0     width=32    height=32    xoffset=0     yoffset=0     xadvance=32    page=0  chnl=15
char id=52   x=132   y=0     width=32    height=32    xoffset=0     yoffset=0     xadvance=32    page=0  chnl=15
char id=53   x=165   y=0     width=32    height=32    xoffset=0     yoffset=0     xadvance=32    page=0  chnl=15
char id=54   x=198   y=0     width=32    height=32    xoffset=0     yoffset=0     xadvance=32    page=0  chnl=15
char id=55   x=0     y=33    width=32    height=32    xoffset=0     yoffset=0     xadvance=32    page=0  chnl=15
char id=56   x=33    y=33    width=32    height=32    xoffset=0     yoffset=0     xadvance=32    page=0  chnl=15

If base is set to 32 it works:

info face="Arial" size=32 bold=0 italic=0 charset="" unicode=1 stretchH=100 smooth=1 aa=1 padding=0,0,0,0 spacing=1,1 outline=0
common lineHeight=32 base=32 scaleW=256 scaleH=256 pages=1 packed=0 alphaChnl=4 redChnl=0 greenChnl=0 blueChnl=0
page id=0 file="Moon2_0.png"
chars count=9
char id=48   x=0     y=0     width=32    height=32    xoffset=0     yoffset=0     xadvance=32    page=0  chnl=15
char id=49   x=33    y=0     width=32    height=32    xoffset=0     yoffset=0     xadvance=32    page=0  chnl=15
char id=50   x=66    y=0     width=32    height=32    xoffset=0     yoffset=0     xadvance=32    page=0  chnl=15
char id=51   x=99    y=0     width=32    height=32    xoffset=0     yoffset=0     xadvance=32    page=0  chnl=15
char id=52   x=132   y=0     width=32    height=32    xoffset=0     yoffset=0     xadvance=32    page=0  chnl=15
char id=53   x=165   y=0     width=32    height=32    xoffset=0     yoffset=0     xadvance=32    page=0  chnl=15
char id=54   x=198   y=0     width=32    height=32    xoffset=0     yoffset=0     xadvance=32    page=0  chnl=15
char id=55   x=0     y=33    width=32    height=32    xoffset=0     yoffset=0     xadvance=32    page=0  chnl=15
char id=56   x=33    y=33    width=32    height=32    xoffset=0     yoffset=0     xadvance=32    page=0  chnl=15

It looks like we have a workaround which works with '0'. I'm not yet 100% sure, because I had fonts working in one app, not working in another.

BR

Andy

FNT is not a file directly included in prg!

That's what the FNT file compiler is for, to check its correctness of it instead of generating some garbage that generates errors on the end device. Why there is no error on the sim? I wrote about problems with fnt files a long time ago, but no one reacted.

Hi forandy, thank you for testing this. I'm wondering what happens if you set 'base' to 32 as well? Does it work then?

oops, misunderstood the workaround. Indeed, base=32 is fixing the issue. Seems above workaround is working :)

Woa that is great news and would mean a lot easier workaround than my current one. I'm waiting for one of my cooperative users with a fr645m to confirm this. Thanks!

Hi Travis,

I think it is the opposite - the base should always be less than the character (not necessarily digit) height.

As far as I can tell, every typical font generated by BMF and containing alphanumeric characters will have the base less than the height.

I wrote more about this in the bug report: forums.garmin.com/.../fr645-and-others-since-fw-7-20-major-issues-with-custom-fonts

It is also interesting why was this change was made in the FW 7.20? It looks like trying to fix something that ain't broke?

I can report that changing base to the maximum of all the height= values fixed the problem on my app for the fr645m.