Webfont vertical metrics strategies

Glyphs app has one strategy for webfonts while Google Fonts has another. Could anyone explain what's going on?


  • Khaled HosnyKhaled Hosny Posts: 98
    edited July 2016
    I think there are lots of legacy complications and superstition when it comes to vertical metrics. So the first question is what are the environments you are targeting and what kind of fonts you are building.

    For example, I target mainly well behaved applications and web browsers, buggy applications are buggy and it is not my job to workaround their bugs. I also build fonts that tend to have some unusually high glyphs. So my strategy is a bit simple:
    • Set typoAscender and typoDescender to the value that give default line spacing that is good enough for common uses of the font.
    • Set typoLineGap to zero, just to avoid dealing with the inconsistency of how applications apply it (I might need to revise this).
    • Set USE_TYPO_MTERICS fsSelection bit, so that applications that honour this use the typo metrics.
    • Set hhea metrics to the same value as typo metrics, so that well behaved Windows and Mac applications give consistent spacing.
    • Set winAscent and winDescent to the maximum value that avoid clipping (this is usually the font bbox plus some room for stacked marks).

    This obviously does not work everywhere, specially on legacy Windows applications that insist on abusing win metrics for line spacing, but it at least gives consistent and sane results in well behaved applications.
  • The (old) Google Fonts strategy was trying mainly to address the use of win metrics in line spacing, by forcing the same value in the three metrics. This works for basic Latin fonts, but it starts to break apart once you start expanding your charset. This is currently being revised since there are no major browsers suffering from this issue anymore.
  • Ray LarabieRay Larabie Posts: 525
    I use Typekit's strategy for vertical metrics. I release many of my fonts with one or several free styles. Free fonts probably end up on all manner of buggy applications so I prefer to use the best worst-case-scenario metrics settings. The Typekit system is the best one I've found.

    But I cut off my vertical metrics at the top of the Å and let the Vietnamese and any other tall accent stacks go past the line. It may not be the proper strategy but if I try to accommodate tall accent stacks some applications will squeeze the entire font down really tiny. In most applications those Vietnamese accents still appear. It's a trade-off.

    I wish I had a link I could share with you but I couldn't find it. I'm not sure if they've ever published it.
  • I want to confirm that was the vertical metrics policy, but as Khaled says, this is being revised, so I've just updated that file to point to the new policy's development in this googlefonts-discuss thread in the last weeks :)

    Ray, could you describe it here?
  • Ray LarabieRay Larabie Posts: 525
    I have no idea if this is the current recommendation for TypeKit fonts. This is how I did it back in the pre-Adobe days. The Vietnamese accent part is my own preference.

    This the 1000 emsquare version. You'll have to scale it if you want a different emsquare. This method assumes you want as little vertical slack as possible. Scale everything so the distance between the lowest point and the top of the Å comes to 1200, not including Vietnamese stacks*. If you've already designed your typeface and you want to scale to fit, try this: X=current vertical dimensions. 120000 ÷ X = scaling percentage. Scale everything and your font should now be exactly 1200 units vertically. Keep in mind that if you keep the top tight, the smoothing on the apex of the Å might look too sharp in some applications. You may want to leave a 4 unit gap on the top if it's not a squarish design. Your lowest point is probably a comma accent so you can keep it tight on the bottom.
    • OS/2 TypoAscender = highest point − 200
    • OS/2 TypoDescender = lowest point
    • OS/2TypoLineGap =  200
    • OS/2 WinAscent = highest point
    • OS/2 WinDescent = lowest point
    • hhea Ascender = highest point
    • hhea Descender = lowest point
    • Linegap = 0
    If you're making a typeface with no descenders or accents, like a dingbat font, this system doesn't work well. It seems to work fine with run-of-the-mill Latin proportions.

    * Unless it's a display typeface and you're crushing your Vietnamese accents stacks to match the Å.
  • Ramiro EspinozaRamiro Espinoza Posts: 479
    edited January 11
    @John Hudson How do you turn the fsSelection bit 7 on? With OT Master?

  • Since I'm the main developer of FontCreator I do know how to accomplish it in FontCreator:

  • Kent LewKent Lew Posts: 487
    Ramiro — The relevant attribute via Robofab is
        f.info.openTypeOS2Selection = [7]
    But I don’t think this is supported in FontLab .vfbs.

  • @Ramiro Espinoza There's a variety of tools that can do this. I've done it in OTMaster, but you have to interpret the numeric representation in order to affect change. 

    0x0040 -> Regular
    0x00c0 -> Regular Use_Typo_Metrics

    If you're a Glyphs user, you can add it in the Font Info panel:

  • In RoboFont the setting can be changed in the font info directly.

  • otfcc:

    your_font.OS_2.fsSelection.useTypoMetrics = true
  • As mentioned in the dialog of FontCreator that Erwin posted above: when applying the ‘typo metrics’, the ‘OS/2’ table has to be set to version 4 or higher. OTM can also be used for this.

    FYI, here are a few more bit settings:

    (Decimal / hex)

    Regular = 64 / 0x0040
    Regular + Typo Metrics = 192 / 0x00c0

    Regular WWS = 320 / 0x0140
    Regular WWS  + Typo Metrics = 448 / 0x01c0

    Italic = 1 / 0x0001
    Italic + Typo Metrics = 129 / 0x0081

    Italic WWS = 257 / 0x0101
    Italic WWS + Typo Metrics = 385 / 0x0181

    Bold = 32 / 0x0020
    Bold + Typo Metrics = 160 / 0x00a0

    Bold Italic = 33 / 0x0021
    Bold Italic + Typo Metrics = 161 / 0x00a1
  • @LeMo aka PatternMan aka Frank E Blokland I think it would be a huge usability improvement to display the fsSelection bits not as a single number, but a field of bits/checkboxes like in the RoboFont screenshot above.

    I sure know how to calculate the value, but I have tried to explain it to less math-savvy people and their faces just turn into big question marks ;)

    On a loosely related note, what is the best way to report OTMaster bugs? I’m probably the only person in the world reading TrueType instruction code, but it has been bugging me for a long time that in OTMaster the high/low bytes are mixed up. In the screenshot below, the number in byte 14/15 should read 0x01ff (dec. 511), not 0xff01 (dec. 65281).

  • Hi Jens, I am pleased to know that at least one person in the world is reading TrueType instruction code.  ;) Thanks for the note. Bugs in OTM can be send to <bugsinotm@dutchtypelibrary.com>. The checkboxes are on our list for the upcoming update of OTM.
Sign In or Register to comment.