Font metrics settings for desktop and web fonts

Ramiro EspinozaRamiro Espinoza Posts: 660
edited August 14 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.




Comments

  • John HudsonJohn Hudson Posts: 1,415
    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: 763
    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: 958
    edited August 12
    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: 1,415
    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: 177
    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 FoleyMarc Foley Posts: 3
    edited August 13
    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, 

    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 :smile:
  • 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: 1,415
    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).
  • 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 HosnyKhaled Hosny Posts: 211
    Most type designers I know are making fonts that would not be functional with such compromise.
  • Thomas PhinneyThomas Phinney Posts: 1,055
    edited August 14
    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.
Sign In or Register to comment.