Align hhea to sTypoMetrics when useTypoMetrics flag is set?

[aaronbell]

I am implementing a production pipeline for Cascadia Code using a UFO-based build workflow and have set the 'useTypoMetrics' flag in the font. As such, I'd expect the hhea values to be the same as the sTypoMetrics values, but instead it appears that the hhea values are aligning with the winAscent and winDescent values.

If that flag is set, shouldn't the hhea and sTypoMetrics be the same?

[anthrotype]

by default the hhea linegap is set to 0, and the hhea.ascender also includes the typoLineGap (thus it is wider than the typoAscender). This is because a non-zero hhea.lineGap would increase the effective line spacing on some Windows environment (see "external leading" in https://docs.microsoft.com/en-us/typography/opentype/spec/recom#baseline-to-baseline-distances).

I think ufo2ft doesn't do anything special when that useTypoMetrics flag is set, it simply compiles it as is.
If you'd like to work on a PR to make generation of vertical metrics fallbacks smarter, you're very much welcome.

[adrientetar]

Maybe we should also set useTypoMetrics by default

[madig]

Not sure. There are still problems with e.g. linux text rendering libraries not doing line gap.

[aaronbell]

As a follow up on this, I was looking at the Vertical Metrics instructions on the GoogleFonts docs and it makes this recommendation:

Set these values to be the same across all masters to ensure that output instances have equal vertical metrics:

TypoAscender and hheaAscender are set to height of tallest uppercase glyph with single accent (probably  or Å)
typoLineGap and hheaLineGap set to 0
TypoDescender and hheaDescender set to lowest a-z letter (p, j, q)
winAscent and winDecent set to yMax and yMin (absolute highest and lowest point in the font)
fsSelection bit 7 enabled
In GlyphsApp, set Use Typo Metrics custom parameter set to true in the Font tab of Font Info.
In RoboFont, this is under Font Info > OpenType > OS/2 Table > fsSelection > USE_TYPO_METRICS.

Thoughts?

[madig]

Sounds as sensible as any other strategy I suppose. There are a few, foundries like to have their own and applications all do whatever they want anyway. Ideally, you settle on one and explicitly set what you want in your source files. Don't rely on defaults.

[aaronbell]

Agreed. I just figure might as well follow the Google Fonts standard as default as this is under the Google Fonts repository :)

[chrissimpkins]

@madig do you have more information on this comment in the thread above?

Not sure. There are still problems with e.g. linux text rendering libraries not doing line gap.

What GNU/Linux env issues are at play with line spacing and typo v metrics?

[madig]

You can follow the links in https://gitlab.gnome.org/GNOME/cantarell-fonts/-/issues/37.

[chrissimpkins]

tyvm!