Repository navigation
[css-inline] The web de-facto requires nonnegative line gap metrics in fonts #5064
Description
Firefox and Chrome both run web fonts through the OpenType Sanitizer, which rewrites the font file. One of the things it does is clamp line gap metrics so that they aren't negative.
WebKit got a compatibility bug about this, since WebKit wasn't doing the same clamping. I've committed a change in WebKit to align with the other browsers and perform the clamping.
Because now all the browsers agree, and it is de-facto required for the web, the CSS fonts spec should say so (somewhere).
Activity
astearns commentedon May 13, 2020
Is the line gap metric clamping the only thing this sanitizer does that you think is required for web compat?
Are these metrics allowed to be negative per the OpenType spec?
litherum commentedon May 13, 2020
This is the only thing I'm aware of today. Perhaps we will discover more in the future.
The spec says they are of signed type. It doesn't say anything about negative values. https://docs.microsoft.com/en-us/typography/opentype/spec/hhea and https://docs.microsoft.com/en-us/typography/opentype/spec/os2
css-meeting-bot commentedon Apr 28, 2021
The CSS Working Group just discussed
[css-fonts] The web de-facto requires nonnegative line gap metrics in fonts, and agreed to the following:RESOLVED: Fonts with negative line gaps are clamp at 0The full IRC log of that discussion
<dael> Topic: [css-fonts] The web de-facto requires nonnegative line gap metrics in fonts<dael> github: https://github.com//issues/5064
<dael> myles: Pretty straightforward. Browsers do it but not in spec.
<dael> myles: If font says it has negative line-gap it's clampped at 0
<dael> Rossen_: Anyone with different opinion why this shouldn't be the case?
<dael> Rossen_: Obj to Fonts with negative line gaps are clamp at 0
<dael> florian: Quesiton, have you checked this is true of print formatter?
<dael> myles: No, haven't checked. FF, Chrome, and WK do it
<dael> florian: Sounds like a good idea, wondering if done in print and how we deal with compat. Maybe just suggest they do it as well
<dael> Rossen_: This is why we have standards
<dael> RESOLVED: Fonts with negative line gaps are clamp at 0
<dael> myles: I think metric is within inline spec so I think this issue should be parented under that spec
<dael> Rossen_: Sure
[-][css-fonts] The web de-facto requires nonnegative line gap metrics in fonts[/-][+][css-inline] The web de-facto requires nonnegative line gap metrics in fonts[/+]litherum commentedon Apr 28, 2021
Oh, this probably also affects the grammar of
line-gap-overridein css-fontslitherum commentedon Apr 28, 2021
Oh, looks like this was already done in 348ed35
[css-inline-3] Floor line gap metric at zero. #5064