W3C home > Mailing lists > Public > public-css-archive@w3.org > February 2020

[csswg-drafts] Interoperable font metrics (#4792)

From: Myles C. Maxfield via GitHub <sysbot+gh@w3.org>
Date: Wed, 19 Feb 2020 02:22:06 +0000
To: public-css-archive@w3.org
Message-ID: <issues.opened-567273076-1582078925-sysbot+gh@w3.org>
litherum has just created a new issue for https://github.com/w3c/csswg-drafts:

== Interoperable font metrics ==
In font files, there exist at least three different ascent/descent values:
- `ascender` and `descender` from the [`hhea` table](https://docs.microsoft.com/en-us/typography/opentype/spec/hhea)
- `sTypoAscender` and `sTypoDescender` from the [`OS/2` table](https://docs.microsoft.com/en-us/typography/opentype/spec/os2)
- `usWinAscent` and `usWinDescent` from the [`OS/2` table](https://docs.microsoft.com/en-us/typography/opentype/spec/os2)
- 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. https://github.com/w3c/csswg-drafts/issues/2228 is an example of one. There have been others.

There have been efforts to try to introduce "interoperable" metrics into CSS (https://github.com/w3c/csswg-drafts/issues/3978 is one, https://github.com/w3c/csswg-drafts/issues/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:

```CSS
@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 default features present in the font file.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4792 using your GitHub account
Received on Wednesday, 19 February 2020 02:22:09 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:42:00 UTC