The question is: What is best practice in setting the vertical metrics of a webfont so that there is enough room to grow the language set of the font without having to expand those vertical metrics upward and/or downward later on to accomodate glyphs with a ymax or ymin greater than the global ascent/descent values originally set?
Now that webfonts have truly put the word "World" into the term "World Wide Web", whenever you offer a new font, it makes more and more sense to assume that it's initial Latin character set is just a first step, or is simply there for convenience so that the browser doesn't fall back to another unknown font for Latin characters.
For arguments sake, let's stick to a 2048 units per em, since that is still the most common in TTFs.
And to keep the font's behavior as consistent as possible across browsers and platforms there are two more assumptions considered best practice:
The two linegap values will be set to zero. (0)
The three ascent values - hhea, sTypoAscender, and usWinAscent - will be identical.
The three descent values - hhea, sTypoDescender, and usWinDescent - will likewise be identical.
There is a font that ships with Windows for Arabic named Trado that has exactly those metric constraints so it's a good example. Here's a screenshot of what it looks like in DTL OTMaster.
My presumption is also (but I'm not at all sure about this), is that the ascent and descent values will be set to match, respectively, the yMax and yMin values of the descents and ascents of any glyphs that might be added later.
(Now, the yMax and yMin values can be altered to reach beyond the actual ascent of the tallest standing and the actual descent of the lowest hanging glyph(s). But if you're adding extra room above and below the glyphs that exist, is it necessary for the yMin and yMax to agree with the global values hhea and usWin, and sTypo? Or can they just be left alone to reflect the outer boundaries of the glyphs that currently exist? I have no idea if the engines that interpret the font info make any use of the yMin/yMax values at all. I just don't know and if someone could enlighten me on just what those entries are there for - yMin and yMax - and what, if any consequences there might be in altering them, I'd appreciate it.)
Be aware that there's no way to know exactly what the ascent or descent of a glyph added later is going to be.
What is sought is a best-guess number that will leave enough room above and below the baseline to accomodate all but the most extreme scenarios.
For example, there is another font that ships with Windows named Mangal for the Indic script Devanagari.
Both linegaps set to 0.
All ascents set to 2542. All descents set to -898.
However, the yMin/yMax are -1016 and 2743.
So, why the discrepancy? (And BTW - if you look at it in OTMaster and click "check", it auto-recommends the yMin and yMax values for usWinDescent instead of -898 and 2542.
What's up with that?
And so, if anybody has an ascender or descender value - or a formula for deriving them based on the existing Latin glyphs, or the x-height, or whatever - or any comments or light at all to shed on what I've written about here, it might help a whole lot of font makers going forward.
The question is prompted by real-world problems being grappled with by foundries working on a bunch of new fonts targeting non-English speaking language communities at Google Fonts.
And those same problems might be paying YOU - if you're a regular reader of this forum - a visit real, real soon.
And it would be nice to have answers.
BTW - If you're new to the topic or had no idea web font metrics and "desktop" font metrics were different animals, the following link is a good intro with a list of links at the bottom. The blog at Glyphs (the font editing app) also has a good little tutorial on metrics. https://code.google.com/p/googlefontdirectory/wiki/VerticalMetricsRecommendations