harfbuzz
BASEv2?
https://typedrawers.com/discussion/comment/70471/#Comment_70471
What @tiroj says here makes a case to me for a BASEv2?
That sounds like something we decided can be done with existing BASE table, and HB exposes it in https://harfbuzz.github.io/harfbuzz-hb-ot-layout.html#hb-ot-layout-get-font-extents2
It isn’t clear to me from the spec that the Min/max extent values defined in the BASE table are intended to be used for linespacing, nor is there any implementation spec that defines how they should be used for linespacing. The section of the spec references ‘figure 5c’ in the preceding section, which illustrates alignment of different scripts, not adjustments to linespacing.
My own view is that if—as it now generally the case—a font indicates that linespacing to be determined using the three OS/2 table Typo values, then what we should have is corresponding three sets of ascender, descender and linegap metrics for individual script/langsys entries.
This is duplicate of https://github.com/harfbuzz/boring-expansion-spec/issues/88
We should make a proposal to MPEG for next round. Other than that, I think the best case scenario would be a major platform implementation. Android was interested in this.
I don't think the lack of linegap poses a major problem for this.
We should ask @nedley for a spec of what Apple is using. As I recall, they use a custom BASE table for adjustments to script linespacing, but not for individual languages.
I don't think the lack of linegap poses a major problem for this.
It would be a kindness to font makers to provide a consistent model for linespacing metrics, as well as making clearer to implementers that these are indeed linespacing metrics to be handled in the same way as the OS/2 Typo metrics and not something akin to the OS/2 Win metrics.
And don’t forget the adage: if there is a way to implement linespacing incorrectly, devs will find it. :)
This is duplicate of https://github.com/harfbuzz/boring-expansion-spec/issues/88
Related, but not a duplicate per se. That issue presumes a solution, i.e. the existing Min/Max extent can be used as ’vertical ascent/descent’. But ascent/descent does not immediately imply linespacing, except in the old GDI broken sense that used WinAscent and WinDescent for linespacing, i.e. the ur-error that started the whole vertical metrics headache.