Font metrics settings for desktop and web fonts

Ramiro EspinozaRamiro Espinoza Posts: 809
edited August 2018 in Font Technology
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.




«1

Comments

  • John HudsonJohn Hudson Posts: 2,128
    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.
  • Thanks @John Hudson. Do you use the same approach for webfonts?
  • 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 LarabieRay Larabie Posts: 1,093
    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 CrosslandDave Crossland Posts: 1,106
    edited August 2018
    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 HudsonJohn Hudson Posts: 2,128
    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.


  • AbrahamLeeAbrahamLee Posts: 251
    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.
  • k_lk_l Posts: 41
    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 HudsonJohn Hudson Posts: 2,128
    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_lk_l Posts: 41
    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.
  • Most type designers I know are making fonts that would not be functional with such compromise.
  • Michael JarboeMichael Jarboe Posts: 263
    edited August 2018
    @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 PhinneyThomas Phinney Posts: 2,058
    edited August 2018
    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 JarboeMichael Jarboe Posts: 263
    edited August 2018
    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.
  • 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.
  • 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 PhinneyThomas Phinney Posts: 2,058
    edited August 2018
    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.


    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.
  • 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.
  • 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?
  • 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?)
  • I'm breaking my head over this stuff again.
    Would there be something wrong if typoAscender + typoDescender +typoLineGap does not equal winAscent + winDescent?
  • 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
  • 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!
  • I do not know how it is taken care of in FontLab, but this is how it works in FontCreator:


  • Erwin DenissenErwin Denissen Posts: 234
    edited January 2
    And here is a tutorial that further explains best practices concerning these metrics:

  • Thomas PhinneyThomas Phinney Posts: 2,058
    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.
Sign In or Register to comment.