hhea.advanceWidthMax might be a bad value to rely on for monospace_max_advancewidth check

Observed behaviour

In Recursive Mono, I get notified that This seems to be a monospaced font, so advanceWidth value should be the same across all glyphs, but 99.6% of them have a different value.

 >> com.google.fonts/check/monospace_max_advancewidth
    Monospace font has hhea.advanceWidthMax equal to each glyph's advanceWidth?
    with fonts_1.036/Static_OTF/RecursiveMonoLnr-ExtraBold.otf

    * WARN: This seems to be a monospaced font, so advanceWidth value should be the same across all glyphs, but 99.6% of them have a different value: space, uni00A0, uni2007, uni2008, uni2
009, uni200A, A, Agrave, Aacute, Acircumflex and 1232 more. [code: should-be-monospaced]
    * WARN: Double-width and/or zero-width glyphs were detected. These glyphs should be set to the same width as all others and then add GPOS single pos lookups that zeros/doubles the widt
hs as needed: uni02BC, uni0300, uni0301, uni0302, uni0303, uni0304, uni0306, uni0307, uni0308, uni0309 and 60 more. [code: variable-monospaced]

    Result: WARN

However, this assumes that the font’s maximum width value is its primary width value, which is not the case here. Rather, the normal value is 600 units, and the maximum of 2400 comes from only a few code ligatures.

1099 of 1247 glyphs have a width of 600, meaning that only 11.87% of them have a different value. Moreover, a check shows that all glyph widths are divisible by the normal width of 600 with no remainder, so the font should theoretically have no issues of non-monospaced glyphs.

Of course, some terminals (e.g. the VS Code terminal) will not work with glyphs over the 600-unit width, but those also don’t support dlig, so the only problems I’ve run into in the VS Code terminal are:

1. The f.italic gets cut off because it goes beyond its sidebearings
2. I occasionally get a warning about it being a non-monospaced font (but it still works, anyway)

Expected behaviour

Instead of basing the “correct” monospace value on hhea.advanceWidthMax, I think it might make sense to base it on something like the space or a glyph.

If there is reason to base it on the hhea.advanceWidthMax, we should at least update the check rationale to say why we are flagging it as a WARN, and perhaps calculate the “different value” metric.

Resources and exact process needed to replicate

Here’s a recent version of Recursive which can be used for this check:

https://github.com/arrowtype/recursive/blob/1a1680256d89d6856f9e4eef06ceae247a804537/fonts_1.036/Static_TTF/RecursiveMonoLnr-ExtraBold.ttf

[felipesanches]

thanks, @thundernixon! If we can craft a short rationale text describing the actual purpose of the check, we can open a new issue to either bring back the check or to implement a new, reasonable one.

[arrowtype]

(Though, this ignores that I think code ligatures can be better as dlig than as calt. I need to try the Fira code width hack with dlig, to see whether that can work. If so, I could write a document on GitHub about the workflow, and we could link to that.)