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?
What do you think of it? I am looking forward to hear your opinions.
Comments
SIL's 'best practices' document disappointingly doesn't even mention the fsSelection bit 7 mechanism and the situations in which it might be relevant.
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.
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.
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.
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
I like SIL's approach a lot, actually, as it renders all earlier vertical metrics black magic superfluous.
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:
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).
- Design typeface, set metrics that work at that time.
- Publish typeface.
- Need or want to retrofit it later for Vietnamese.
- Discover that they are hosed as far as vertical metrics, in being able to add Vietnamese while maintaining any backwards compatibility.
- 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.
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.
Ấ
(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.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.
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.
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.
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.
Would there be something wrong if typoAscender + typoDescender +typoLineGap does not equal winAscent + winDescent?
I think it is on by default, but I might have changed that.