OS/2 fsSelection useTypoMetrics
Aaron Bell
Posts: 93
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
Thanks!
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
Thanks!
0
Comments
-
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.0 -
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.0
-
I set it for all my fonts (Arabic and math) since almost always the Win metrics are (much) bigger than the Typo ones.
0 -
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.0 -
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.1 -
For the issue I had, both for screen and printing turning off the use_typo_metrics flag fixes the line spacing issue.0
-
If it's helpful, this will set a the useTypoMetrics bit to false for a folder of fonts: https://github.com/Typefounding/setUseTypoMetricsFalse2
Categories
- All Categories
- 43 Introductions
- 3.7K Typeface Design
- 805 Font Technology
- 1K Technique and Theory
- 622 Type Business
- 444 Type Design Critiques
- 542 Type Design Software
- 30 Punchcutting
- 137 Lettering and Calligraphy
- 84 Technique and Theory
- 53 Lettering Critiques
- 485 Typography
- 303 History of Typography
- 114 Education
- 68 Resources
- 499 Announcements
- 80 Events
- 105 Job Postings
- 148 Type Releases
- 165 Miscellaneous News
- 270 About TypeDrawers
- 53 TypeDrawers Announcements
- 116 Suggestions and Bug Reports