I am working to onboard a set of Traditional Chinese fonts to Google Fonts using the new vertical metrics requirements agreed to in this thread. However, it appears that Glyphs’ implementation sets the glyph height to follow the difference of the sTypoAscender and sTypoDescender. This makes sense if you have set these values to align with the emBox, but if one is trying to do something different (such as the approach mentioned in the thread above) it becomes problematic.
As I have found, Glyphs will not generate the vhea and vmtx tables if the vheaVertAscender, vheaVertDescender, and vheaVertLineGap values are not set. It seems to me that those values should be the default for determining glyph heights, when the designer has not set the glyph height values manually.
So if I have a font which has a sTypoAscender of 940, a sTypoDescender of -180, but vheaVertAscender of 500 and vheaVertDescender of -500, the vmtx table heights should be 1000 instead of 1120.
This approach would still enable folks to set the sTypo metrics following the old way, and would also enable setting them in the new way (which allows for better horizontal typesetting).
I mean, this is where the BASE table becomes very handy since that information is stored in there.
Otherwise, you can make an educated guess by summing the sTypo value like you did before, subtracting the UPM, divide by 2, and subtract that from the sTypo Ascender.
Maybe not as neat as it was before but it’ll work.
Actually, rather than the UPM, maybe subtract the sum of the vheaVert metrics (which would also be 1000)? That way if someone designs a weird rectangular embox even on a 1000 UPM font, the embox height would be defined correctly in the vheaVert data.
I was reminded on the issue I posted on glyphsLib that the vhea data is intended for left/right edge spacing—I must have confused the edges.
To that end, I think that the approach I suggested above where we use the sTypo sum / subtract the UPM / divide by two would provide the best to ensure proper spacing.
I’ve submitted a PR to glyphsLib which resolves this issue:
Essentially it:
Checks if there’s a BASE table and pulls values from there if it can
Checks if the sum of the sTypo values exceeds the font upm, then calculated the em-box based on the difference
Barring the above, uses the existing logic.
The code is badly un-optimized (I have to evaluate the BASE table every time) but doing something more savvy will involve more plumbing than I feel comfortable getting into at the moment, but I wanted to demonstrate how the system could work to accurately produce glyph heights rather than relying on the sTypo values.
