Webfont vertical metrics strategies

Wei Huang

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

Khaled Hosny

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.

Khaled Hosny

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 Larabie

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.

Dave Crossland

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 Larabie

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 Å.

John Hudson

This is how we've been making fonts for Microsoft for many years:

1. The OS/2 TypoAscender and TypoDescender height should sum to the em unit total. I usually calculate this by starting with the actual ascender (Latin lc 'd' height) and actual descender (Latin lc 'p' height'), calculating their relative proportions, and proportionally adding to these to make up the difference between these values and the em height.

2. The OS/2 TypoLinegap should be the appropriate distance for desired default linespacing for the design. A lot of Latin type designers always set this to 20% of the em height; personally I prefer a slightly wider default linespacing, especially since the fonts I am making tend to be used in word processing or other situations with longer line length.

3. The OS/2 WinAscent and WinDescent values should define the non-clipping zone for the typeface, so should equal the height and depth of the tallest glyphs in the font, unless that total is less than the sum of the TypoAscender, TypeDescender and TypoLinegap heights. If it is less than that sum, then the WinAscent and WinDescent values should be increased to equal the sum of the Typo values; this enables compatibility in software that uses the Win values for linespacing. [In some cases, if the sum of the Win values is only slightly larger than the sum of the Typo values, I will either increase the latter slightly to match, or will reduce the former and allow a little clipping. If possible, I try to maintain compatibility between Typo and Win values because of the amount of software out there that still doesn't respect the fsSelection bit 7 setting.]

4. If the sum of the Win values exceeds the sum of the Typo values, then fsSelection bit 7 should be turned on. This signals to software that the Typo values should be used to calculate linespacing instead of the Win values. Despite the fact that it is twelve years since this bit was defined, there is still a lot of software out there that doesn't respect it, which is why I try whenever possible to make the Typo and Win values compatible.

5. If we have set fsSelection bit 7 to use OS/2 Typo metrics for linespacing, then we set the hhea Ascender, Descender and LineGap to match the corresponding OS/2 Typo values. If not, then we set the hhea Ascender to equal the OS/2 WinAscent, and the hhea Descender to equal the WinDescent, and the hhea LineGap to 0 (zero).

Ramiro Espinoza

@John Hudson How do you turn the fsSelection bit 7 on? With OT Master?

Erwin Denissen

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

Kent Lew

Ramiro — The relevant attribute via Robofab is

    f.info.openTypeOS2Selection = [7]

But I don’t think this is supported in FontLab .vfbs.

Aaron Bell

@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:

Paul van der Laan

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

Belleve Invis

otfcc:

your_font.OS_2.fsSelection.useTypoMetrics = true

LeMo aka PatternMan aka Frank E Blokland

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

Jens Kutilek

@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).

LeMo aka PatternMan aka Frank E Blokland

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.