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

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.

Can confirm the same issue on FR645M.

ERA logs show this is system error:

Error Name: System Error
Occurrences: 47
First Occurrence: 2023-02-11
Last Occurrence: 2023-02-21
Devices:
    Forerunner® 645 Music: 7.20

Crash appears on loadResource.

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.

Any feedback from Garmin would be appreciated. When could we expect a fix? I'm seeing so many customer emails (+reviews) about this which is getting annoying. I could implement a workaround for all, but that's quite cumbersome, as it needs to be reverted as well once this is fixed by Garmin.

Not all fonts.  char id=48 is the character for "zero" and that works fine with a number of my fonts.