Support for font metrics values for override

[caraya]

The Fonts Level 4 Editor Draft includes default font metric overrides for ascenders, descenders, and line gap. These are now supported in Chrome (@font-face descriptors to override font metrics)

Is it possible to query the HHEA table for the font being analyzed and present that data to the user so they can use the data for overrides?

[RoelN]

That is a good idea!

How would you like to see this data presented? Say you want to set the ascent-override and descent-override of your font, and this is the naked data from the font:

UnitsPerEm: 1000
ascent: 1025
descent: -275
linegap: 0

Wakamai Fondue could show the percentages for the CSS properties:

@font-face {
  ...
  ascent-override: 102.5%;
  descent-override: 27.5%;
  line-gap-override: 0%;
}

(Not entirely sure if positive descender values are legal in fonts, otherwise I guess it's a matter of making them positive, as "negative values are invalid at parse time.")

[caraya]

Parsed values would be better. I'm not familiar with the conversions I would have to make to get them working in CSS. The code also needs to tell people that even though the values for the font come from the web font, they should be applied to the local fallback font (and it should use the local() descriptor).

Thanks!

[RoelN]

Different browsers use different metrics to determine ascender/descender/line height:

hhea.ascender hhea.descender hhea.linegap OS/2.sTypoAscender OS/2.sTypoDescender OS/2.sTypoLineGap OS/2.usWinAscend OS/2.usWinDescend

So which ones should Wakamai Fondue present as the metrics that will be used in the real world? Note to self: figure out which are the most commonly used metrics in browsers, and use those to propose CSS.

[RoelN]

https://github.com/w3c/csswg-drafts/issues/4792

[litherum]

Different browsers use different metrics to determine ascender/descender/line height:

This is exactly the problem that these override CSS descriptors are trying to solve. This is why the browser can't just "do the right thing" - different answers are correct on different OSes/browsers. The browser needs additional information from a third party (aka the CSS author) in order to have consistent renderings across OSes/browsers; it's entirely possible that WF needs additional information too, for the exact same reason.

[RoelN]

Current plan:

Translate metrics to percentages. Use https://github.com/googlefonts/gf-docs/tree/master/VerticalMetrics to determine "best" metrics, select those by default. (Currently thinking this is OS/2 typo, also see https://twitter.com/boldmonday/status/1350125003510067201)

Offer other metrics in a dropdown? Only when the deviate from "best metrics"?

Theoretically, either metric should be fine as the font designer sets these to be the same. Except when some metrics are tweaked to work around quirks in a specific environment.

Relevant Twitter thread: https://twitter.com/PixelAmbacht/status/1350059386731954176 (be sure to click at random on tweets as there are a lot of replies which Twitter helpfully hides/shows complete willy nilly)

[vhoyer]

~Hey, ppl, sorry to be dumb, but, I see you used UnitsPerEm: 1000. Is that set by the font, or is this the default universally?~

EDIT: sorry, I just found the metric :facepalm:, it's in the head section, right? oh well, sorry for bothering, but if I can give my 5 cents:

if we tell the users to apply the override descriptors in, both, the fallback and the target font, we don't need to worry about what metric to use, since the user will be using the metrics that the tool provide.

What do you think?

[RoelN]

@vhoyer Yes, it comes from the head! Regarding picking the best metrics, we have a few choices so there must be some logic behind which one we want to show first, right? But I think I know what to do here. Now for some time to implement it :-)

[RoelN]

From Karsten Luecke, via mail:

The OS/2 UseTypoMetrics flag was meant to tell MS's Office applications, specifically, that they should use the OS/2 Typo values rather than the OS/2 Win values. It was not meant to say: instead of the hhea values. This implies that any other applications would choose the OS/2 Typo values anyway, regardless of what this flag says.

[ZerdoX-x]

guys, what's the state of this? :eyes:

[RoelN]

Unfortunately I've been caught up in other projects, and have little free time to work on the fondue right now :-( I hope to pick this up in the winter sometime.

[HolmesSoftware]

Any update on this feature? I would love to see it implemented

For those looking I found this was a good alternative for my personal use case perfect-ish-font-fallback

[RoelN]

Hi everybody, thanks for your patience. Unfortunately I was/am preoccupied with other projects. I have implemented something similar for a different project so I hope to be able to port it to Wakamai Fondue when time permits!

[RoelN]

Hey, this tool is doing a great job! https://github.com/unjs/fontaine