[csswg-drafts] [css-fonts-4] Definition of `normal` for font-palette not well-defined or interoperable (#9281)

drott has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-fonts-4] Definition of `normal` for font-palette not well-defined or interoperable ==
https://www.w3.org/TR/css-fonts-4/#font-palette-prop describes the `normal` property value as follows.

> User-Agents attempt to treat the color font as closely as possible to a non-color font. In particular, user-agents use a palette which will yield the best default result for reading. User-agents may take the computed value of the [color](https://www.w3.org/TR/css-color-4/#propdef-color) property into consideration when making this decision. User agents may also construct and use a palette not defined in the font.

I describe below why I find this definition here not well defined and how it lacks interoperability:


### Lack of interop / algorithmic description for discretion of palette choice
* "In particular, user-agents use a palette which will yield the best default result for reading."

Other than with `USABLE_WITH_(LIGHT|DARK)_BACKGROUND` there are not attributes on the palettes in the font that would let the user agent algorythmically choose such a palette. 
https://learn.microsoft.com/en-us/typography/opentype/spec/cpal#palette-type-array

What we can define here is only: "User agents choose the default palette of the color font to render glyphs." 

* "User-agents may take the computed value of the [color](https://www.w3.org/TR/css-color-4/#propdef-color) property into consideration when making this decision. "

Is similarly weakly defined and not helpful or interoperable without an algorithmic description of what should happen. What is the idea here? Should there be some sort of similarity score between a foreground color and a set of palette colors? I suggest to strip this. 

### Lack of interop / algorithmic description for synthetisation of "monochromatic-looking" palette

> "User agents may also construct and use a palette not defined in the font." 

What would be the use case here or how would a user agent be successful with that? Is the idea here to compute a default grayscale palette that matches luminosity of the default color palette of the font?

### Glyph selection preference should be the colored glyph

> "User-Agents attempt to treat the color font as closely as possible to a non-color font." 

I tend to disagree with that. When the font has a color-glyph in `SBIX`, `CBDT/CBLX`, `COLR` or `SVG ` tables, in the spirit of incremental enhancement that glyph should usually be preferred over the monochromatic variant when the UA supports the color font format, as it provides the richer representation. 

There is no useful automatic conversion to a monochromatic glyph from these color glyphs. If the intention is a text representation, the font can either be subsetted to strip color tables, or provide [CMAP format 14](https://learn.microsoft.com/en-us/typography/opentype/spec/cmap#format-14-unicode-variation-sequences) tables with variation sequences to control which glyph should be chosen.

### Glyph choice control available through UVS or should be defined as separate CSS prop

Control over glyph choice i.e. should the rendered glyph come from the `COLR` table or the monochromatic `glyf` table is better controlled by separating the font instances and subsetting the font into two instances, or a separate CSS property for the purpose.

### Proposal

I suggest to reduce the `normal` definition to say:

> User-Agents prefer colored glyphs where available and render the font with the default palette. Monochromatic glyphs should be rendered in the color specified by the [color](https://www.w3.org/TR/css-color-4/#propdef-color) property.


Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9281 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 31 August 2023 12:30:33 UTC