Clarify rationale and log messages: check/041: WARN: Checking Vertical Metric Linegaps.

Observed behaviour

I’m getting the warning from Google Fonts check 041:

⚠️ WARN: Checking Vertical Metric Linegaps. – hhea lineGap is not equal to 0. [code: hhea]

Expected behaviour

Based on the GF-docs specification of vertical metrics, I expect the lineGap to be ¼ of the UPM:

Typo LineGap = 0.25 * UPM Hhea LineGap = Typo LineGap

These two specs contradict one another, correct?

Additionally, I have run fixfonts.py from gftools on the source, which I would expect to set the correct lineGap.

Should I ignore the warning, or have I missed something? Is the warning correct and simply relevant for other fonts? Or, is it something that could be updated to reflect the GFdocs spec?

Resources and exact process needed to replicate

My latest VF build and the associated FontBakery report is here: https://github.com/thundernixon/Libre-Caslon/tree/5792567921c8df8c23ddeabf56b27c9250f0baaa/dist/2018-11-06-21_09

In the parent Libre Caslon repo, the build script can be run in a py3 environment with scripts/build.sh. Two gftools lines are currently failing (gftools-fix-nonhinting.py & gftools fix-gasp), but the rest will build and be put a VF and report into a new, timestamped folder inside dist. (Yes, I’ll clean this working directory up when this font is published).

[m4rc1e]

Deleted my previous comment since it’s no longer relevant.

While I’m clarifying our vert metric docs and tests, I’ll provide evidence/research to support it. I’d like to dig deeper on this,

[m4rc1e]

We have multiple sources of truth here which isn’t good. Since Dave wants hhea metrics and typo metrics to match, we should update this doc and fb checks.

I will happily take this on as a task next week. I’ll also update the doc due to new discoveries:

Setting metrics for new families

I’ve recently found including linegaps to be a problem. When I had linegaps, the accents on the first line of text would often get clipped in primitive editors. It would’ve been more beneficial to include the linegap values in the ascenders to stop this from happening.

I recently pushed a lot of Thai families which had the following setup:

• TypoAscender and hheaAscender are set to height of tallest Cap glyph with single accent (Â, Å)
• Linegaps set to 0
• TypoDescender and hheaDescender set to lowest a-z letter (p, j, q)
• Win Ascent and Win Decent set to yMax and yMin
• fsSelection bit 7 enabled
• Vertical metrics on average were around 130% of upm. I felt this number was the sweet spot. Anything greater and the metrics just looked too loose.

Yes Vietnamese text will produce collisions but the user can solve this by increasing css line-height or increasing linespacing in editors. I think this approach is better than having metrics which are so loose you can drive a bus through each line.

Setting metrics for upgraded families

If hhea and typo don’t match, we must decide which set must be used. I suggest that hhea metrics should be changed to match the typo because there are more win/android users than Mac citation needed.