10BC0 [css-fonts-4] Definition of `normal` for font-palette not well-defined or interoperable · Issue #9281 · w3c/csswg-drafts · GitHub
[go: up one dir, main page]

Skip to content

[css-fonts-4] Definition of normal for font-palette not well-defined or interoperable #9281

@drott

Description

@drott

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 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 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 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 property.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    Status

    Friday Morning

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

      0