search

fonttools / fontbakery

🧁 A font quality assurance tool for everyone
https://fontbakery.readthedocs.io
Apache License 2.0
557 stars 103 forks source link

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

Open thundernixon opened 6 years ago

thundernixon commented 6 years ago

Observed behaviour

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

and

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

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

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

===

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. :/

HinTak commented 6 years ago

The GF doc recommendation talking about vertical metrics and hhea is weird - there is a vhea table for vertical metrics, you know...

Argh, I see this sort of (mis-)usage in Glyphs' doc. That's unfortunate as "vertical metrics" has a different meaning in the opentype spec...

thundernixon commented 6 years ago

Sorry, maybe something like "platform-specific vertical metrics" would be a better term?

HinTak commented 6 years ago

What you are talking about are vertical sizes/distances in horizontal layout... The more usual meaning of "vertical metrics" are horizontal sizes/distances in vertical layout...

m4rc1e commented 6 years ago

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.

HinTak commented 6 years ago

The actual code is in https://github.com/HinTak/Font-Validator/blob/master/OTFontFileVal/val_OS2.cs , no need to speculate.

This is basically how the source code is organized - one file per opentype table, "val_*.cs"

davelab6 commented 6 years ago

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.