OS/2 fsSelection useTypoMetrics

I've recently been learning more about the OS/2 fsSelection useTypoMetrics flag and was wondering how commonly type designers set that flag in your fonts. Do you set it in your fonts? Or purposefully not? 

For those unfamiliar, the useTypoMetrics flag indicates to DirectWrite to use the sTypo metrics values instead of the usWin metrics values for display of fonts.

More info here: https://www.microsoft.com/typography/otspec/os2.htm#fss



  • John HudsonJohn Hudson Posts: 2,973
    We use it if there's some reason why the sTypo metrics differ from the usWin metrics (in terms of linespacing behaviour). So, for instance, in math fonts we need huge usWin metrics to accommodate things like tall integral signs, but obviously don't want that to determine default linespacing (or scaling in font menu preview).

    If a design doesn't actually require different sTypo and usWin metrics, then we don't set that bit.
  • John HudsonJohn Hudson Posts: 2,973
    I have a very vivid memory of the very crowded hotel conference room in Prague where Si and I presented a proposal for this bit setting to assembled font makers in 2004. A lot of people were sitting on the floor, while others stood around the walls.
  • Khaled HosnyKhaled Hosny Posts: 289
    I set it for all my fonts (Arabic and math) since almost always the Win metrics are (much) bigger than the Typo ones.
  • Ben KielBen Kiel Posts: 34
    edited March 2017
    I just ran across a user issue with setting this bit when hhea and typo are different (which is how I usually set things so that Word doesn't clip accents — there is no tech support email like the tech support email when the dieresis is clipped from caps).

    The problem is with different versions of Word — in the newer versions, it seems to have started to respect this bit, so documents may have different line spacing. Turning off this bit seems to solve this. 

    To be honest, it shouldn't make a difference in line spacing, as the way things are set in the fonts are to have the hhea ascent, descent, and line gap values sum to the typo ascent, descent, and line gap values — but it does. I think I'm going to chalk up the visual difference to the fact that the typo values, by virtue of having line space set to a value that isn't 0, means that visually the font shifts up, though it's possible something else is going on.
  • We've been dealing with the Word2016 line spacing problem.
    Older versions of Word display and print using the usWin ascender/descender values. 
    But in Word 2016, text is displayed using the sTypo ascender/descender/lineGap, but then printed using usWin. 

    I was hoping that it was a simple error on the part of a programmer (used sTypo when they should have used usWin), but it's been a few months and we haven't seen any updates.

    From MS:
    Specifically, you have the "USE_TYPO_METRICS" flag set in the OS/2 table (under fsSelection) which instructs the renderer to use the sTypo* metrics instead of the usWin* metrics. My suspicion is that Word2016 respects that flag, whereas Word2011 does not. 
  • Ben KielBen Kiel Posts: 34
    edited March 2017
    For the issue I had, both for screen and printing turning off the use_typo_metrics flag fixes the line spacing issue.
  • Ben KielBen Kiel Posts: 34
    If it's helpful, this will set a the useTypoMetrics bit to false for a folder of fonts: https://github.com/Typefounding/setUseTypoMetricsFalse
Sign In or Register to comment.