Font metrics settings for desktop and web fonts

Ramiro Espinoza

Hi there,

I would like to know if this classic approach to font metrics settings for desktop is still considered to be valid. Are you still using this scheme? How do you adapt it for webfonts?

In accordance with this recommendations some people are switching to the following approach for desktop and webfonts:

What do you think of it? I am looking forward to hear your opinions.

John Hudson

The first schema you illustrate is what I still use, at least in fonts where its okay for the Typo and Win values to sum to the same total height. When that's not the case, then I set the hhea values to match the OS/2 Typo values and turn on fsSelection bit 7. That bit isn't respected by all software, but I'm not going to compromise on preferred linespacing or allow clipping just because some developers can't be arsed to implement something that's been in the OT spec since 2004.

SIL's 'best practices' document disappointingly doesn't even mention the fsSelection bit 7 mechanism and the situations in which it might be relevant.

Ramiro Espinoza

Thanks @John Hudson. Do you use the same approach for webfonts?

Connor Davenport

Hi Ramiro, I attached an image of two features files to illustrate how I set up the v-metrics. The left is desktop while the right is for the exact same style's webfont. So in short, I do exactly what you described in your images above. 

Ray Larabie

I still use the original TypeKit method. It's similar to the top example but TypoDescender is the same as Descender and TypoAscender is 200 less than Ascender. The font is scaled so the lowest point (ogonek or comma accent) to highest point (A ring) is 1200 or slightly less. Stacked Vietnamese accents can go higher.

Dave Crossland

The second method is what Google Fonts suggested from 2010, based on research by Raph Levien. (GF doesn't distinguish between desktop and web builds, but when a trade off is required, what is best for the web is what is done.)

However, a couple of years ago Alexei Vanyashin, Kalapi Gajjar, and Marc Foley did a major review of this stuff, and have a newer proposal (using fsSelection bit 7) that is written up in detail here:

https://github.com/googlefonts/gf-docs/blob/master/VerticalMetrics.md

Of those 3 folks, Marc is the only one currently still doing work on the Google Fonts library, and I've invited him to comment on this thread.

John Hudson

However, a couple of years ago Alexei Vanyashin, Kalapi Gajjar, and Marc Foley did a major review of this stuff, and have a newer proposal (using fsSelection bit 7) that is written up in detail here ...

Nice. Those recommendations are what I do when I am making a font in which the sum of desired linespacing metrics differs from the sum of Win non-clipping metrics.

I am wondering, though, whether the same recommendations apply when making a font in which all three sets of metrics sum to the same total height (as is pretty common with Latin fonts for European language, and which provides backwards compatibility with Windows GDI layout that uses Win metrics for linespacing)? For a while, I've been setting the metrics in such fonts so that

hheaAscender = WinAscent
hheaDescender = WinDescent
hheaLinegap = 0 (zero)

This was because of earlier reports that this produced more consistent handling of distance of first baseline from top of text frame between Windows and Mac.

I'm happy to go back to making the Typo and hhea metrics identical in all cases, but would be interested in Marc's insights on this question.

AbrahamLee

Thanks for the link to the GF Regression tool, @Dave Crossland! I’m excited to use that tool since it can compare any two fonts, not just those hosted by GF.

Marc Foley

Please note, I rarely work on new families. I spend most of my time upgrading existing families. The Google Fonts api doesn't support versioning. This means updates are rolled out to all users. We can't just change things as and when we feel. 

When we release new families, we have to ensure we can add new scripts, without changing the visual appearance of the vertical metrics. Even if all three sets of metrics have the same values, we enable OS/2's fsSelection bit 7 for future proofing purposes. When the bit is enabled, we can freely set the win Ascent and Descent to match the font's yMax, yMin which may change when we add new scripts. I echo John's sentiments on vendor support for bit 7. However, there was a good discussion on this bit's potential caveats, http://typedrawers.com/discussion/1605/os-2-fsselection-usetypometrics


Here's a few edge cases which haven't been mentioned in this thread which are worth considering.

Accent Clipping
If you set the vert metrics too tightly, you may clip any accents which are on the first line.

Acircumflex clipped in Mac OS X Text Edit

How much space do you have?
If you're creating a UI font, you must understand what the maximum bounds are. This is incredibly important if the family has tall/deep scripts such as Devanagari, Arabic etc. John's TypoLabs talk on Nirmala had a good section on this, https://youtu.be/6plR8Y6NNJw?t=14m40s

I know this sounds obvious but I've been involved in several projects where these constraint weren't discovered/understood until the very end. We've then had to modify the design to fit within the bounds.

If you're developing a custom family for a client, what family have they used to produce mockups?
I wouldn't stray too far from the dimensions of the family they're currently using, unless you've made it clear that you are not responsible for text reflow etc.


I'm more than happy to answer any other questions. I'm by no means an expert in this area. I'm very fortunate that I only have to deal with fonts that are predominately for the web

k.l.

SIL's 'best practices' document disappointingly doesn't even mention the fsSelection bit 7 mechanism and the situations in which it might be relevant.

The point of SIL's approach is that all three sets are identical in terms of values so that it does not make a difference which of these sets an application chooses. They are identical after all. Hence it is pointless to mention this OS/2 fsSelection bit. Whether set or not, whether encouraging applications to choose the Typo set or not, it does not make a difference.
I like SIL's approach a lot, actually, as it renders all earlier vertical metrics black magic superfluous.

John Hudson

The point of SIL's approach is that all three sets are identical in terms of values so that it does not make a difference which of these sets an application chooses. They are identical after all. Hence it is pointless to mention this OS/2 fsSelection bit.

And yet the SIL document goes into discussion of circumstances in which making all the metrics identical can result in having to make compromises with clipping of glyphs:

There is one situation where you may still wish to set the ascender value lower then the tallest point and higher than the lowest point. In some fonts that have extremely high stacking diacritics, it may be OK to set the ascender value in such a way that the tallest diacritic could get partially cut off. Otherwise the default line spacing in some apps will be far too large and your users will complain. 

Not to mention the option of an existing mechanism that prevents such clipping seems negligent, even if one advises against it for specific reasons that might also be given.

Further, the limitation of this part of the discussion to a single circumstance of 'extremely high stacking diacritics' ignores several other circumstances and seems very particular to the kinds of fonts that SIL is making. The use of fsSelection bit 7 to diverge Typo and Win metrics is essential in math fonts, and I would say too in display fonts with excessively large swashes such as Zapfino and Gabriola; indeed I would say that allowing any glyph to clip on screen, as SIL suggest, is a bad idea since it may affect the reading of a text (the reason we had to go to such painful lengths to avoid clipping of Indic scripts in Nirmala UI while forcing them into the inherited metrics of Segoe UI).

k.l.

SIL's document is clear about its objective – and its limitation. Section ‹Internal font line spacing settings› refers to another approach, then correctly acknowledges that ‹there is no good solution that works everywhere, so a compromise is best›, and proceeds to state this simplified compromise which should more than suit the kind of fonts made by the majority of type designers. These type designers ask a simple question – ‹which values shall I use?› – and expect a simple answer. Not a bunch of ifs and thens. There is a last section ‹Other references› for type designers who would like to dig deeper.

Khaled Hosny

Most type designers I know are making fonts that would not be functional with such compromise.

Thomas Phinney

The basic thing that still kills many type designers who think they are safe because they are just doing Latin-based fonts is this one:

1. Design typeface, set metrics that work at that time.
2. Publish typeface.
3. Need or want to retrofit it later for Vietnamese.
4. Discover that they are hosed as far as vertical metrics, in being able to add Vietnamese while maintaining any backwards compatibility.
5. Hit head on desk, repeatedly.

So, one piece of advice I have both heard and given, is: assume you will need to be able to accommodate stacked Vietnamese diacritics in any Latin font you make, whether or not you initially design such diacritics.

Yes, I know this ignores the problem of how much space to allot—how much space do you allow if you haven’t designed the diacritics yet? But even a quick rough take would be better than not doing it, you would at least have constraints you could maybe work within later. Instead of having completely unworkable constraints.

Michael Jarboe

@Thomas Phinney To avoid this problem, couldn't one in theory select and design the 'one' Vietnamese glyph/combined accents, with the highest vertical metrics need, set corresponding metrics to accomodate this extreme, and then be prepared for any future Vietnamese glyph expansion?

I'm especially curious in the moment as I'm very close to launching a new foundry with a couple key releases that are all but finalized/mastered. I've always had the interest in potentially supporting Vietnamese, but this problem never occurred to me. The last thing I want to do is add any more significant design/development time, and I don't particularly like the idea of roughing in metrics.

I think I'll continue having an internal debate of extra work, versus regret, versus the percent chance I'll ever support Vietnamese. I always imagined I'd look to support Cyrillic and Greek, before Vietnamese, but we'll have to see.

Thomas Phinney

That is pretty much what I mean to suggest, either design or at least rough out the tallest accent combination, which would be circumflex + acute (or circumeflex + grave): 

Ấ

(In most fonts that stacks up higher, it depends....) Try that on an E and an A, aee how much space it needs. Make sure your font is set up to accommodate that, and away you go.

Michael Jarboe

Easier than it sounded initially. I love the simplicity to that glyph being that it's 'only' an acute/grave attached to circumflex (at least in comparison to what I recall as more complex Vietnamese accent combinations). I'll have to do a quick test and measure, but I believe that my /Aringacute (does anyone use this glyph?) might actually stack higher than the /Acircumflexacute, so maybe I'm already set? We'll see.

I was thinking that all of this is simplified further being that this measurement can be done at the most extreme of the boldest master only. I use the technique of applying the most extreme vertical metrics to all weights for interfamily vertical metrics consistency.

Jeff Kellem

Thomas Phinney said:

That is pretty much what I mean to suggest, either design or at least rough out the tallest accent combination, which would be circumflex + acute (or circumeflex + grave)

The hook above or tilde tone marks combined with Ê or Ă, for example, might be a little higher, depending on your design decisions.

Kent Lew

What Jeff said.

I should think that uppercase breve+hookabove breve+tilde or circumflex+tilde would generally stack higher than circumflex+acute.

And yes, generally if you’re already clearing your Aringacute, there’s a good chance you’ll be prepared to accommodate the Vietnamese, I should think.

Artur Schmal

Thomas Phinney said:

So, one piece of advice I have both heard and given, is: assume you will need to be able to accommodate stacked Vietnamese diacritics in any Latin font you make, whether or not you initially design such diacritics.

Are you recommending that these stacked diacritics fit within ascender height, or should they fall partially in the linegap. In the first case, the type will be rather small on the body.

Thomas Phinney

Artur Schmal said:

Are you recommending that these stacked diacritics fit within ascender height, or should they fall partially in the linegap.

They need to fall within usWinAscent height, or else they will be clipped in many/older Windows apps. There are numerous approaches to your overall vertical metrics coordination, so the answer beyond that depends on which schema you are using... and whether you consider clipping of accents in old apps acceptable.

Artur Schmal said:

In the first case, the type will be rather small on the body.

Yes, it may need to be a bit smaller. That is one of the reasons for sorting this out up front in the design process. Speculation: Ever notice how the average cap height across most old fonts is about 70% of the em square, but it is noticeably smaller for the ClearType fonts? Calibri is about 10% smaller than that. Cambria and Consolas are not as dramatically smaller, but still smaller. I have not done a careful survey, but just looking at data in a spreadsheet I put together (for different purposes), it seems like modern text faces designed by professionals might on average have smaller cap heights than the fonts of The Old Days.

Artur Schmal

Thomas Phinney said:

Yes, it may need to be a bit smaller. That is one of the reasons for sorting this out up front in the design process. Speculation: Ever notice how the average cap height across most old fonts is about 70% of the em square, but it is noticeably smaller for the ClearType fonts? Calibri is about 10% smaller than that. Cambria and Consolas are not as dramatically smaller, but still smaller. I have not done a careful survey, but just looking at data in a spreadsheet I put together (for different purposes), it seems like modern text faces designed by professionals might on average have smaller cap heights than the fonts of The Old Days.

Yes, I looked at Calibri as well, it is 63% of the em square, and the highest point of Aringacute is exactly on the winAscent height.

Johannes Neumeier

Out of curiosity: Any of you that have retrospectively changed vertical metrics of a font with an update, how much customer support or other feedback has this caused?

Mark Simonson

I inadvertently did it a few years ago with Proxima Nova. It was in the hhea values, which are used on iOS. A customer who was using it in an iPhone app complained, which prompted me to restore the original values. The incorrect values were present in the fonts for over a year.

I suspect that customers tend to use the version they got when they purchased the license, and don't often seek out updates. That would explain why I got no other complaints about it anyway.

Johannes Neumeier

Thanks @Mark Simonson for that insight. I suspect for Google Fonts the situation is a lot different with the fonts being "redistributed" with every of the millions of pageloads their fonts get. Nonetheless, I wonder if for the average font vendor introducing such change is actually a non-issue, especially when it come with an actual update to the font. Curious to hear more opinions on this, as long as we're not diverging too far from the original topic. (I think we are not, are we?)

Artur Schmal

I'm breaking my head over this stuff again.
Would there be something wrong if typoAscender + typoDescender +typoLineGap does not equal winAscent + winDescent?

Jason Campbell

Artur Schmal said:

I'm breaking my head over this stuff again.
Would there be something wrong if typoAscender + typoDescender +typoLineGap does not equal winAscent + winDescent?

see the latest entries in this thread: http://typedrawers.com/discussion/3069/internal-leading-in-vertical-metrics-is-it-necessary#latest

Claudio Piccinini

John Hudson said:

The first schema you illustrate is what I still use, at least in fonts where its okay for the Typo and Win values to sum to the same total height. When that's not the case, then I set the hhea values to match the OS/2 Typo values and turn on fsSelection bit 7. That bit isn't respected by all software, but I'm not going to compromise on preferred linespacing or allow clipping just because some developers can't be arsed to implement something that's been in the OT spec since 2004.

SIL's 'best practices' document disappointingly doesn't even mention the fsSelection bit 7 mechanism and the situations in which it might be relevant.

Hi John, I am reflecting on this to find a satisfying approach to use on all of my typefaces from now on. Could you explain how the "fsSelection bit 7" thing works? I am working in Fontlab 7 and I really do not have any experience in coding. Thanks much!

Erwin Denissen

I do not know how it is taken care of in FontLab, but this is how it works in FontCreator:

Erwin Denissen

And here is a tutorial that further explains best practices concerning these metrics:

https://www.high-logic.com/font-editor/fontcreator/tutorials/font-metrics-vertical-line-spacing

Thomas Phinney

In FontLab 7, the same setting is under File > Font Info > Other Values, "Family Dimensions" section, "Prefer Typo Metrics" checkbox.

I think it is on by default, but I might have changed that.