[css-text-decor-4] Add use-font keyword for text-decoration-width & text-decoration-offset

[drott]

In the WG minutes from February 2017 and the discussion in issue 459 there were references to adding a keyword to text-decoration-width and text-decoration-offset. @fantasai suggested to use use-font as the keyword name.

Quite possibly I missed earlier discussions on this, that's why I am asking to clarify:

Can we add such a keyword and specifying is as adhering to the definitions of underlinePosition and underlineThickness in the post table of the OpenType specification?

[drott]

PS: Since currently browser do various things for auto, like applying a fixed scaled underline depending on font-size, etc. or maintain whitelists/blacklists for what fonts have sane values, I think having use-font would be a good way to transition away from this magic and explicitly select what the font designer had in mind.

[fantasai]

Agenda+ to get an official WG resolution on adding this, and to ask if there's preference on what keyword to use. I think use-font and from-font were suggested.

[litherum]

If we do this, we need language to give browsers enough freedom to perform platform-dependent "fixup" to these font values. For example, CoreText performs its own fixup before WebKit even calls into it to get these values.

[litherum]

Also we need to specify which font in the font-family cascade list is used for gathering these metrics.

[svgeesus]

Also we need to specify which font in the font-family cascade list is used for gathering these metrics.

Perhaps the same criterion as we use elsewhere: the first font to have a glyph for 0x20 space.

[drott]

If we do this, we need language to give browsers enough freedom to perform platform-dependent "fixup" to these font values. For example, CoreText performs its own fixup before WebKit even calls into it to get these values.

Would it be sufficient if this fixup would only be applied in the auto case, whereas use-font would use information straight from the font? Can you explain more what sort of fixup this is?

[fantasai]

@litherum We use the “first available font”, as always.

[litherum]

Can you explain more what sort of fixup this is?

CoreText uses a heuristic to guess when a font has bad data, and if it detects bad data, it synthesizes new values and exposes those.

If WebKit wanted to use literally what the font file says, it would have to parse the font file tables itself. This would be unfortunate because the CoreText synthesized data will be of higher quality than the font file itself (that's the whole point of the synthesis).

[svgeesus]

We use the “first available font”, as always.

@fantasai So if the first available font does not have a space glyph, the underline position will be taken from a different font than the rest of the font metrics? That seems odd.

[fantasai]

@svgeesus We use the “first available font” for a variety of operations that are relevant: the sizes of font-relative units, the height and baseline position of the line, etc. We should consistently use it for every operation for which we need a single set of font metrics. And the position and thickness of an underline for a given element is a single set of metrics.

If you have a problem with how the “first available font” is found, file an issue against that. Also if we for some reason have multiple concepts of “first available font”, we should consolidate them into one. There should only be one “first available font” per element, regardless of operation.

[drott]

Can you explain more what sort of fixup this is?

CoreText uses a heuristic to guess when a font has bad data, and if it detects bad data, it synthesizes new values and exposes those.

If WebKit wanted to use literally what the font file says, it would have to parse the font file tables itself. This would be unfortunate because the CoreText synthesized data will be of higher quality than the font file itself (that's the whole point of the synthesis).

I see there are cases when what's in the post table for underlinePosition and underlineThickness cannot be used to draw anything. I wouldn't totally object to stating that the browser can switch to auto / do something suitable if the values are totally invalid, but I would slightly prefer if we can avoid undocumented magic.

Can we perhaps dig in and describe the criteria for when use-font would ignore what's in the font? For example: fall back to auto when underlinePosition is 0x0000, or say larger than the ascent? What would be reasonable criteria? If can't come to a conclusion about such cut-offs, I am okay with leaving this up to implementations.

[litherum]

I would prefer not to specify CoreText implementation details.

[css-meeting-bot]

The Working Group just discussed ] Add use-font keyword for text-decoration-width & text-decoration-offset, and agreed to the following resolutions:

• RESOLVED: about adding a use-font (name to be bikesheded) keyword for these text decoration metrics

The full IRC log of that discussion

<dael> Topic: ] Add use-font keyword for text-decoration-width & text-decoration-offset
<dael> github: https://github.com//issues/2376#issuecomment-371376593
<dael> fantasai: Suggestion to have a keyword to use metrics in font. Proposals were use-font and from-font. We're open to other ideas. Resolution I'm looking for is a keyword for this thing. I vaguely recall another property with a similar keyword, but I couldn't find it.
<dael> astearns: I don't recall
<dael> myles: I think having a new keyword is fine. Point I raised in the issue is that implmay want UA dependant fixus if font has rediculous values.
<dael> fantasai: That's fine.
<dael> florian: Do you plan that for a known list?
<dael> myles: It's done automatically so I can't comment on specific algo, but it's impl detail on how we perform the fixup.
<dael> florian: Okay.
<dael> astearns: Spec would say use font would use metrics from first available font if they are reasonable?
<dael> myles: Or just say it would similar metrics to the font...that's bad...I'm not sure exact text.
<dael> myles: You could have a second sentence saying UA MAY synth values. I'll defer to fantasai . She can do a good job.
<myles> s/fixus/fixup/
<dael> astearns: Question is if we add this keyword. Does anyone have concerns about adding a use font keyword for these text decoration metrics
<dael> astearns: Obj?
<dael> astearns: I'm assuming use font is what we should use.
<dael> fantasai: Use fotn and from font are the top two.
<dael> astearns: Use sounds better to me.
<liam> i prefer from-font
<dael> fantasai: We're not dead set on this if there's a better idea.
<liam> since the font's glyphs aren't used.
<florian> +1 to from-font, but no objection to the other one
<dael> RESOLVED: about adding a use-font (name to be bikesheded) keyword for these text decoration metrics

[drott]

Ping about bikeshedding the name, perhaps you can agree on a keyword name while meeting in Berlin. Thanks.

[css-meeting-bot]

The Working Group just discussed Bikeshed font underline value names, and agreed to the following resolutions:

• RESOLVED: use from-font

The full IRC log of that discussion

<dael> Topic: Bikeshed font underline value names
<dael> github: https://github.com//issues/2376
<dael> myles: THere's 2 properties to describe the geomeptry of text decoration. Move up and move down. Increase size. Fonts also include information about where font desigener thigns decorations should be. We resolved to add keywords to say use what's in the font file. We have not found names.
<dael> myles: One is from-font and one is use-font
<dael> fantasai: Also match-font
<dael> TabAtkins: We have a from-image keyword.
<dael> fantasai: Anyone impl?
<dael> TabAtkins: Dunno.
<dael> fantasai: I like your point that they should be consistent.
<dael> astearns: Objections to from-font?
<dael> RESOLVED: use from-font