Families should reserve vertical space for stacked diacritics (even before having such glyphs)

[felipesanches]

Stacked diacritics are common on scripts like Vietnamese

New font families should have reserved vertical space for future glyph coverage expansion into scripts that would require stacked diacritics, otherwise, it would be tricky to do so without breaking vertical metrics on documents typeset with previous releases of the font files.

I am not sure which heuristics to use for such a check, but I'd like to invite the community to propose reasonable approaches. My first thought about this topic yesterday was that the required extra vertical space could be the height of Agrave plus the height of gravecomb (effectively, that would be approximately the height of an uppercase A plus twice the height of a commonly present diacritic). But @tphinney suggested that we might not need that much perhaps.

On a second thought, though, @tphinney also considered (if I recall it correctly) that the Vietnamese hook is relatively tall...

@davelab6, @vv-monsalve, @RosaWagner, @m4rc1e, @twardoch and others, please let me know your suggestions here.

[vv-monsalve]

I was suggesting Abreveacute (which is included in the GF Latin Plus) as a reference instead of Agrave since it could be a good average in height (taller than Agrave but possibly not too tall as Abrevehookabove).

But this is still part of the test I'm performing to update our Vertical Metrics recommendations doc.

[RosaWagner]

Two fonts that comes in mind: https://github.com/RosaWagner/BeVietnamPro https://github.com/JetBrains/JetBrainsMono

[vv-monsalve]

Space Grotesk includes a reviewed Vietnamese and vertical metrics carefully adjusted by the designer for UI uses https://github.com/floriankarsten/space-grotesk

[tphinney]

One thing to consider is, the check must first see if the font already HAS such Vietnamese diacritics. Otherwise one would be reserving extra space, when one already has the space.

[felipesanches]

@davelab6, we need your opinion here

[davelab6]

Stacked diacritics are common on scripts like Vietnamese

New font families should have reserved vertical space for future glyph coverage expansion into scripts that would require stacked diacritics,

I agree

otherwise, it would be tricky to do so without breaking vertical metrics on documents typeset with previous releases of the font files.

Going forward, I think the most simply thing to do is require type designers to draw that tallest expected glyph, from all glyphs in the script's GF glyph sets, even if the whole set that glyph is part of, is not in scope at that moment. We can add that glyph to the smallest set of the script with a special note about why it exists.

I am not sure which heuristics to use for such a check, but I'd like to invite the community to propose reasonable approaches. My first thought about this topic yesterday was that the required extra vertical space could be the height of Agrave plus the height of gravecomb (effectively, that would be approximately the height of an uppercase A plus twice the height of a commonly present diacritic). But @tphinney suggested that we might not need that much perhaps.

Please back-test any proposed heuristic on some/all of the TTFs in the GF central repo to confirm how good it is :)

You can also probably just make a list of all fonts with an A, or AH, or $all_upper_case, and then from that list, list out each glyph that is taller than those baselines, and for each tall glyph, create a % ratio of how much taller it is, within its font, and across the whole set; and then ultimately a global average %.

And then you can say what the typical relationships are of UPM to cap height to ymax, and compare the currently checked font against those constants.

[davelab6]

I've filed an issue about the glyph set idea in that repo

[davelab6]

For fonts worth paying attention to, since they have very large glyph sets: Questrial has implemented the African Latin set; a few other families (Noto Sans/Serif, Roboto, Arimo, Tinos Cousine, Lato (upstream not from GF), etc) might also support it.

[m4rc1e]

I'm not really such a fan of this proposed solution. I think Khaled summarised it best back in 2016, https://typedrawers.com/discussion/1705/webfont-vertical-metrics-strategies

So the first question is what are the environments you are targeting and what kind of fonts you are building.

For example, I target mainly well behaved applications and web browsers, buggy applications are buggy and it is not my job to workaround their bugs. I also build fonts that tend to have some unusually high glyphs. So my strategy is a bit simple: Set typoAscender and typoDescender to the value that give default line spacing that is good enough for common uses of the font. Set typoLineGap to zero, just to avoid dealing with the inconsistency of how applications apply it (I might need to revise this). Set USE_TYPO_MTERICS fsSelection bit, so that applications that honour this use the typo metrics. Set hhea metrics to the same value as typo metrics, so that well behaved Windows and Mac applications give consistent spacing. Set winAscent and winDescent to the maximum value that avoid clipping (this is usually the font bbox plus some room for stacked marks).

This obviously does not work everywhere, specially on legacy Windows applications that insist on abusing win metrics for line spacing, but it at least gives consistent and sane results in well behaved applications.

"Good enough for common uses of the font" is key here imo. It would be a shame if we start loosening up the metrics just to accommodate Vietnamese diacritics, even though they'll be used by less than < 1% of users (guesstimate) and they may not even exist. It's probably better to set the metrics so they look as comfortable as possible for the primary script which is what we currently do. If users notice accents are clashing, they can increase the leading.

[vv-monsalve]

Going forward, I think the most simply thing to do is require type designers to draw that tallest expected glyph, from all glyphs in the script's GF glyph sets, even if the whole set that glyph is part of, is not in scope at that moment. We can add that glyph to the smallest set of the script with a special note about why it exists.

I would advocate doing this.

It would be a convenient way to publish fonts in a safer way as it would cover all considerations listed on the Notes of our current VM Spec.

It would only require designers to include one or two extra diacritics to generate the requested glyph. It could be probably hookabove as often Acircumflexhookabove or Abrevehookabove, or anyone including that mark, are the tallest glyphs when covering Vietnamese (as per TypeSetIt cases)

[vv-monsalve]

After performing vertical metrics tests (sumarized in this document):

• Current GF-VM specifications were confirmed as working good (VM-test-8 y 9) for non complex scripts (Latin, Greek, Cyrilic).
• Abrevehookabove or would work as a good reference to leave space for stacked diacritics while complying the 130% for the sum of typoMetrics. So it could be added to GF Latin Core encoding. A check ensuring this would be needed. This could supersede #3170.
• After reviewing Tiro Indigo issue reported on vertical metrics, probably the spec for complex scripts should be reviewed and taken to something like typo == hhea == win and linegaps == 0. That is a line height above 1.3 UPM.