• Replies 50 replies
  • Subscribers 27 subscribers
  • Views 7833 views
  • Users 0 members are here
Options
Related

Major Issues with Custom Fonts after latest Device FW-Updates

forandy
over 1 year ago

Hi, the last weeks I had increasing numbers of strange reports of bugs (crashing apps) on most of my apps. It became more and more clear, that mostly it happens after latest FW updates on devices, but I was not able to locate based on log files. On simulator I have absolutely no issue.

This week I updated also my devices and had the same issue. Even on old devices like FR645M (yes, there was also a FW update !!!) after this update I've the same issue.

After many hours it seems to be, that some of the customer Fonts I set up with BMFont64 lead to the crash:

Error: System Error
Details: 'Failed invoking <symbol>'

At code customFont = Ui.loadResource(Rez.Fonts.icons);

I did not change the code, and not all of the fonts are affected. I cannot find any rule if BMFont64 setting is leading to the bug. Already tried to play with BMFont64 settings with no success.

Again it only happens based on devices with the latest FW-Update. And on simulator everything is ok.

Has anyone the same issue and maybe any idea ?

  • over 1 year ago

    This is happening for me too.

    Crash on this line
    digitFont =  WatchUi.loadResource(Rez.Fonts.dFont);
    • Device Name: Forerunner 645 Music (2)
    • Firmware Version: 7.20
  • over 1 year ago

    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.

  • over 1 year ago in reply to Travis.ConnectIQ

    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!

  • over 1 year ago in reply to Travis.ConnectIQ

    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

  • over 1 year ago in reply to Travis.ConnectIQ

    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.

  • over 1 year ago in reply to forandy

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

  • over 1 year ago in reply to VAW.BE

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

  • over 1 year ago in reply to forandy

    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!

  • over 1 year ago in reply to Travis.ConnectIQ

    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?

  • over 1 year ago in reply to ReedWorks

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