Vertical metrics standards

All vertical measurements are from the baseline, so there is never actually a shift in glyph position relative to the baseline as shown in your illustration.

The two usWIN metrics values should properly define, at minimum, the total height of visible glyphs, and be used by software to define the zone outside of which shapes may be clipped in line layout. This is supposed to work independently of the linespacing metrics, but historically was misapplied in Microsft’s old GDI text engine and used to determine linespacing. This led to a long practice of font makers trying to set these usWin metrics to be equivalent to the sum of the usTypo and hhea metrics, or for the latter to be set to equivalent to the usWin metrics, which is what led to the LineGap value being set to zero, and the Ascender set to = usWinAscent and the Descender set to usWinDescent. It’s a mess.

In 2004, we introduced the fsSelection bit 7 setting in the OS/2 table to indicate to software that it should use the usTypo values for linespacing rather than the usWin metrics, which enabled a mechanism for software to get away from the GDI misuse of the latter while not breaking existing layout for older fonts. If this bit is turned on, as it now is in most fonts, then in theory the usWin metrics can be safely set as they are supposed to be, to define the non-clipping height. I do this in fonts with very tall ascending and descending glyphs, e.g. math fonts with growing delimiter variants. In typical Latin fonts, I try to maintain compatibility with the hhea and usTypo metrics, simply for legacy reasons and because my experience is that if software developers can find a way to get things wrong when it comes to font metrics, they will.

What I would do in your present situation is begin by confirming that you can fit your tallest and deepest glyphs within a total height of 1200 units, and that linespacing of 120% of text size is an appropriate default for your design (it isn’t always). Then I would set the usTypoAscender, hhea Ascender, and usWinAscent metrics to the same value, which should clear the top of the tallest glyph. Then I would measure downwards 1200 units (or whatever you decide should be the default baseline-to-baseeline spacing distance, and set that as the usTypoDescender, hhea Descender, and usWinDescent value. [Well, I say that is what I would do; I actually don’t like the LineGap = 0 model, and prefer to set my metrics as the specification reads rather than second-guessing how the latest software developer is going to get it wrong.]

As I say, that is what I would do, but I don’t know what software is most important to you or your clients/customers, and hence what might constitute ‘best practice’ for you. There was a time in the 2010s when it was briefly possible to define general best practices, but then new software came long with new assumptions. A few years ago, I got a lot of queries from font makers trying to figure out how to optimise vertical metrics settings for vertical alignment within buttons in Figma. I have been watching software makers get this stuff wrong for more than 30 years, so am disinclined to chase their tails.