GF Docs recommends setting vertical metrics that make line heights different between Windows & Mac, according to fontVal

Observed behaviour

In the GF Docs spec on Vertical Metrics, it is recommended that vertical metrics be set in new fonts such that:

• Typo Ascender = either Cap Height or Ascender height, whichever is tallest
• Hhea Ascender = Typo Ascender
• Win Ascent = Font bbox yMax

and

• Typo Descender = Typo Ascender - UPM
• Hhea Descender = Typo Descender
• Win Descent = Font bbox yMin

However, this prompts two FontVal errors (at least in any font with accents that have points higher than caps and ascenders, including Montserrat):

• ⚠️ WARN MS-FonVal: Ascender is different than OS/2.usWinAscent. Different line heights on Windows and Apple DETAILS: hhea.Ascender = 1443, OS/2.usWinAscent = 1708
• ⚠️ WARN MS-FonVal: Descender is different than OS/2.usWinDescent. Different line heights on Windows and Apple DETAILS: hhea.Descender = -605, OS/2.usWinDescent = 462

Expected behaviour

I would expect to set Hhea and typo values such that they match the winAscent values, to keep line heights across platforms.

If line heights really aren’t intended to be the same between platforms (or they stay the same even with different Hhea and win values), I would expect this warning to not show up once I set vertical metrics as recommended.

Is this potential inconsistency documented anywhere? Is the FontVal error incorrect in stating that line heights will be different? If so, there doesn’t seem to be an issue filed yet, but I could do this if it’s valid.

Resources and exact process needed to replicate

• Download Montserrat-Regular.ttf
• Run FontBakery on it:

fontbakery check-googlefonts PATH/TO/DIRECTORY/Montserrat-Regular.ttf --ghmarkdown fontbakery-report.md

• This is also the case for MarkaziText-VF

===

If these warnings are invalid, please let me know so I can file an issue for FontVal.

In addition, could there maybe be a central doc of which warnings to ignore, in which scenarios? Or does this already exist somewhere? I feel like I’m spending a bunch of time chasing around checks that I’m unsure of the validity of. 😕

[davelab6]

That’s unfortunate as “vertical metrics” has a different meaning in the opentype spec…

In the type design community, no one uses the meaning of the opentype spec. I expect outside of CJK fonts, almost no fonts have a vhea table except Bungee.

I feel like I’m spending a bunch of time chasing around checks that I’m unsure of the validity of. 😕

This Font Val test should be disabled imo.

Marc and Felipe, when you’ve finished going over all the FB checks to doublecheck their priority is set correctly, it would be good to do the same process on the FontVal checks, and make a comprehensive list of which Font Val checks you want to filter.

[m4rc1e]

Since MS Val predates fsSelection bit 7 use_typo_metrics, I’m guessing Ms Val wants all 3 sets of vert metrics to sum the same?

⚠️ WARN MS-FonVal: Ascender is different than OS/2.usWinAscent. Different line heights on Windows and Apple DETAILS: hhea.Ascender = 1443, OS/2.usWinAscent = 1708

If you enable bit7 which we recommend, the winAscent is not used. As the bit suggests, it will use the typo Metrics instead.

This Font Val test should be disabled imo.