Font metrics settings for desktop and web fonts

2»

Comments

  • Claudio Piccinini
    Claudio Piccinini Posts: 686
    @Erwin Denissen, @Thomas Phinney: 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 here:

    «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.»

  • Piotr Grochowski
    Piotr Grochowski Posts: 91
    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:
    httpsyoutrackjetbrainscomapifiles74-982177signMTYwOTg4NjEwMDAwMHwxMS03NDk3MzR8NzQtOTgyMTc3fGdDWENNLW9ZVXctZFVHR1I0UDlBOG1p0D0AaTB6Q1FIazRPVkdHckxCdnRmTlUNCg0D0Aupdated1608716719310
    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.
  • Michael Rafailyk
    Michael Rafailyk Posts: 172
    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?

    UPM: 2048
    Safe top / Win Ascent: 1946
    BBox top: 2297
    Ascender: 1536
    hhea Ascender: 1577

    Abreveacute's top: 2091


Categories