Under Review
over 1 year ago

FR645 and others since fw 7.20: major issues with custom fonts

ConnectIQ apps, watchfaces, widgets with custom fonts are failing and showing the IQ! symbol. See these topics for more information:

https://forums.garmin.com/developer/connect-iq/f/discussion/324531/major-issues-with-custom-fonts-after-latest-device-fw-updates

https://forums.garmin.com/developer/connect-iq/f/discussion/324099/forerunner-645-firmware-7-20-errors

https://forums.garmin.com/sports-fitness/running-multisport/f/forerunner-645-645-m/324599/iq-watch-face-broke-after-7-20-update/1574757#1574757

I'm seeing many reports of unhappy users with failing watchfaces. Please fix this as soon as possible Garmin. 

VAW.BE
Parents
  • over 1 year ago

    Answer from Travis from Garmin:

    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.

Comment
  • over 1 year ago

    Answer from Travis from Garmin:

    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.

Children
  • over 1 year ago in reply to Travis.ConnectIQ

    I'm on a Mac en therefor are using the Hiero tool to convert my fonts. The Roboto font (free download on Google Fonts) causes this issue for example.

    When I manually set base height equal to the size of the 0 char in the .fnt file it works. So I've been through a lot of work to manually adapt all font files for all devices on all my products. It's just super odd this is suddenly handled differently on the FR645M device, while it even still works on the Simulator. 

  • over 1 year ago in reply to ReedWorks

    You are not reading my comment, or have confused yourself by adding lineHeight to the mix.Please re-read the quote from the post above.

    What I said is consistent with what the bmfont docs say.. base is the height from the base line to the top of the tallest glyph. The char height is the height of the full character glyph- the base height plus any descender. But note that I specifically say we consider the digit height to be the height of the ‘0’ glyph, which would not normally have a descender.

    Your font has base height=13, and digit height is either 13 or 17 depending on whether or not ‘0’ is in the character set. If you leave out ‘0’ from the chars, your font will not crash the app. If you put it in, it will crash.

    If you have examples of ttf/otf font files that these conditions do not hold, please provide them.

  • over 1 year ago in reply to VAW.BE

    According to https://www.angelcode.com/products/bmfont/doc/file_format.html,

    common

    This tag holds information common to all characters.

    lineHeight    This is the distance in pixels between each line of text.

    base    The number of pixels from the absolute top of the line to the base of the characters.

    ...

    char

    This tag describes on character in the font. There is one for each included character in the font.

    ...

    height    The height of the character image in the texture.

    So it should be perfectly OK for the glyph height to be larger than the base height. The base is something like the lowest point of an 'o', but not of a 'p'.

    In my app, according to ERA, the crash happens when trying to load a font generated by BMFont which was not hand edited at all and where base=13 and lineHeight=17 and for each character height=17.

    The crash does not happen on loading another font which was hand edited and base == lineHeight.

    So it looks like it is the opposite what Travis says and the workaround would be hand editing all BMF generated fonts, which may yield unpredictable results.