Interoperable font metrics via explicit font metrics overrides

[litherum]

Migrated from #2228 (comment)

In font files, there exist at least three different ascent/descent values:

• ascender and descender from the hhea table
• sTypoAscender and sTypoDescender from the OS/2 table
• usWinAscent and usWinDescent from the OS/2 table
• maybe others???

Different browsers / OSes use different values. In fact, some even use values that are not present in the font file at all. This leads to content being laid out differently on different browsers / OSes. #2228 is an example of one. There have been others.

There have been efforts to try to introduce "interoperable" metrics into CSS (#3978 is one, #938 is related, there are a few others too), to force browsers to agree on which metrics they use. Many of the existing proposals so far have some downsides:

• They require browsers to parse font files, rather than relying on special-purpose font parsing libraries (such as CoreText). A tenet of the web platform is that browsers should be able to delegate responsibility to helper libraries.
• They cause all text to be laid out differently, across every website in the entire web. Such a massive change is too scary from a product development standpoint.
• Any approach which is opt-in for specific cases causes text metrics to not match throughout the page. This can lead to inconsistent spacing and poor typography / webpage design.

However, interoperable font metrics are desirable for many page authors. Here's a compromise proposal that (I believe) solves all the above problems:

What if we add a new descriptor into @font-face to let the CSS author override the metrics of the font? Something like this:

@font-face {
    font-family: "WebFont";
    src: ...;
    ascent-override: 80%;
    descent-override: 20%;
}

Those percentage values are resolved by multiplying by the font size (em box). Negative values are illegal. The browser doesn't have to parse any font files, all browsers will agree on the resolved value, and all text in all situations drawn with that font will use these values.

There's already precedent for this: the font-feature-values and font-variation-values descriptors in @font-face overrides the defaults present in the font file.

[kojiishi]

Thank you for writing this up! /cc @kojiishi @drott

[emilio]

/cc @jfkthame

[Crissov]

The downside of any solution that relies on @font-face is that it does not work for local fonts unless authors reference them with local(), which they hardly do in my experience. Please correct me if Iʼm wrong.

[faceless2]

(other proposals) cause all text to be laid out differently, across every website in the entire web. Such a massive change is too scary from a product development standpoint.

I suspect not applying this to local (or even generic) fonts might be entirely intentional.

It's a good compromise idea - I still think we need leading-override too, as OpenType has at least hhea.LineGap and OS/2.sTypoLineGap defining this.

There are other metrics to consider. Both x-height and cap-height are both in the OpenType PCLT table, and there are the baselines too (in the BASE table). All of these are stored only in one place in the font, so if this issue is purely about removing ambiguity and not about overriding metrics, then I'm not sure whether overriding these is important.

[tobireif]

I really appreciate any and all efforts that have the goal of fixing #2228 .

This here ticket wouldn't solve my use-case in a way that's convenient enough - I'd first have to figure out which percentage values to fill in.

A good solution would allow me (and other web developers) to ensure that the described cross-OS-differences won't happen (in modern standards-based browsers) - in a convenient and quick way, eg glyph-positioning: glyph-bounding-box (the exact names are up to you / the W3C 😀)

Chrome on MacOS:

Chrome on Windows:

[tobireif]

They cause all text to be laid out differently, across every website in the entire web. Such a massive
change is too scary from a product development standpoint.

Any solution should be opt-in.

Any approach which is opt-in for specific cases causes text metrics to not match throughout the
page. This can lead to inconsistent spacing and poor typography / webpage design.

That's the responsibility of the web developer. They can apply it to the whole page or only to portions of it - it's up to them. I think that typically the property would be used for eg a large heading and that's it - the rest of the page would be smaller text (where the issue is eg negligible and which might not use the same font as the heading). In any case - it's the responsibility of the web developer to ensure consistent spacing and good typography etc. (That's the exact reason why I had posted #2228 😀 because I was trying to do just that.)

[tobireif]

If your proposal is the only/last offer by the W3C for solving the issue(s) described in #2228 , then I guess I should accept it (towards then closing that ticket) - if it solves the issue(s) described in #2228 completely, and although it requires a bit more work than I had wished for.

[khaledhosny]

One can already override font provided line spacing with CSS line-height and it does not require any font parsing either, what additional benefit one would get from the proposed @font-face overrides?

[jfkthame]

Setting line-height is not sufficent -- within a given line-height, where does the baseline of the text go? This depends on the relative ascent & descent metrics.

[faceless2]

Yes, you can set a specific line-height every time you use that font and get consistent cross-browser results for line-spacing.

But it seems if you're overriding ascender/descender, on which the default value of line-height depends, you might also want to set the default line-height (edit: by setting the leading) as well. It's not necessary, but it will save you specifying line-height everywhere you use the font. If the stylesheet defining the font is being imported by someone not familiar with the modified metrics, this is probably quite important.

[jfkthame]

It seems to me we could reasonably use CSS properties (not just font-face descriptors) here: something like font-ascent, font-descent and font-linegap, all with initial values of auto (meaning the browser derives metrics from the font or from system APIs or whatever), but with authors having the possibility to use percentages (to be resolved based on em size) instead.

normal line height would then be based on the used values of these metrics.

Then it might also be useful to have these as font-face descriptors, which would allow webfonts to override the result of auto, while leaving system fonts to do their normal thing. So authors could choose to take control just for a specific web font (using the descriptors), or to override the browser's auto behavior for arbitrary content in any font (using the properties). All this would be opt-in for authors, so there's no risk to existing content.

An author could then choose to do something like

:root { font-ascent: 80%; font-descent: 20%; font-linegap: 10%; }

and expect to get consistent line-spacing behavior across browsers and platforms -- with the understanding that the result may not be the same as any given browser currently gives by default, but it's entirely under their control.

I suppose the metrics properties (not descriptors) should probably accept absolute lengths, calc expressions, etc. for completeness, although em-based percentages would usually be the most sensible thing to use.

The final piece would be to add a from-font value to each of these properties (distinct from auto), and define exactly what it means in terms of metrics from an OpenType font file; I would suggest the sTypo* values would be the appropriate choice. (This might require browsers to peek into font files, if system APIs don't provide the required metrics, so may be less convenient to implement.)

[tobireif]

@khaledhosny wrote:

One can already override font provided line spacing with CSS line-height

line-height:normal does not help, see #2228 (comment)

Chrome on MacOS:

Chrome on Windows:

line-height: 1 does not help either, see #2228 (comment)

@faceless2 wrote:

Yes, you can set a specific line-height every time you use that font and get consistent
cross-browser results for line-spacing.

The issue is not only about line-spacing 😀The issue is shown in the above screenshots. When it appears it appears even for a single line or word, on one OS vs another (more at #2228 ).

@jfkthame wrote:

Setting line-height is not sufficent

True!

[litherum]

@jfkthame

The final piece would be to add a from-font value to each of these properties (distinct from auto), and define exactly what it means in terms of metrics from an OpenType font file

I believe this fails the “browsers having to parse font files” test.