[fill-stroke] Standardized text-stroke behavior in COLR table fonts

[yisibl]

The -webkit-text-stroke property is currently implemented in all major browsers, browsers behave differently when encountering COLRv0 format fonts.

Safari can add strokes to COLRv0 format fonts, but Firefox and Chrome do not, and the COLRv0 format is so widely used today that we need to standardize it to avoid compatibility differences. Test case

@litherum says:

Safari’s behavior seems more correct than Firefox’s to me. Do you prefer Firefox’s rendering?
https://twitter.com/Litherum/status/1459233815256125445

With the COLRv1 format coming to OpenType 1.9 and released in Chrome, we also need to clarify how this property interacts with SVG tables and COLRv1.

@drott @jfkthame

[yisibl]

#4795

[litherum]

The content said "please stroke this text" so we're stroking the text. That seems natural to me...

[jfkthame]

The content said "please stroke this text" so we're stroking the text. That seems natural to me...

I'm not entirely convinced this is a good idea.... it's clear enough what "stroking the text" means when dealing with monochrome glyphs (just stroke the glyph outline instead of filling it), but it's much less clear how to "stroke" a full-color image. Stroking the outline of each individual colored region may sometimes work OK, if the glyph is not overly complex, but it will often result in an incomprehensible mess.

(What do you do with bitmap glyphs when the content says "please stroke this text"?)

[jfkthame]

Another point of view might be that COLR glyphs are often not really "text" as people would traditionally understand it; they're often (most often, maybe?) used for inline images. The fact that we use Unicode codepoints and OpenType font technology to conveniently encode, deliver and render these images is an implementation detail, but conceptually 🎃 or 🦃 or 🎅 is an image, and the request "please stroke this text" isn't applicable to it.