It looks like you're new here. Sign in or register to get started.
Technique and Theory
Type Design Critiques
Type Design Software
Lettering and Calligraphy
Technique and Theory
History of Typography
Suggestions and Bug Reports
Font metrics settings for desktop and web fonts
: Thanks much to both.
I seem to understand now. Based upon the decisions I made about "Linegap" my usWinAscent and usWinDescent values equal to the sum of Ascender+Linegap and Descender+Linegap, so I guess it should be fine to leave the option unchecked, considered what Microsoft states
«If a font was created with an earlier version of the OS/2 table and is updated to the current version of the OS/2 table, then setting bit 7 could create potential for reflow of existing documents which use the fonts. To minimize such risk, the bit would be set only if using the OS/2.usWin* metrics for line height would yield significantly inferior results than using the OS/2.sTypo* values.»
Unsigned Win Ascent and unsigned Win Descent are the font height boundaries and are critical to optical correction as vertical spacing should be optically correct.
Here is a visualization of what font rendering looks like:
The red horizontal lines are font height boundaries. The font top of the first line marks the top of the text. Exceeding vertical boundaries will lead to clipping. To ensure optically correct vertical alignment and spacing the font height boundaries must be carefully set by the font designer and any change of font height boundaries requires redesigning the entire font to optically match.
When Ascent and Descent are components of the em-size, they are not stored in TrueType. So that is not relevant but the em-size is critical as it determines the unit scale.
The Typo and HHead metrics are not as reliable as unsigned Win Ascent and unsigned Win Descent because they cannot be used to determine the font top and font bottom, and therefore the alignment and spacing, if the gap is true (not equal to 0). Either set gap to 0 and match the values for compatibility, or make them deliberately broken for deliberate incompatibility.
edited May 2021
Checked the Helvetica's vertical metrics on macOS and found a Abreveacute is above the Safe top. Adobe applications says it's ok. But Textedit and Safari (didn't check any others) cuts off upper part of acute. Is this acceptable?
Safe top / Win Ascent:
BBox top: 2297
hhea Ascender: 1577
Forum Software Powered by Vanilla