New check: com.google.fonts/check/color_cpal_brightness

[yanone]

Description

    Layers of a COLRv0 font should not be too dark or too bright. When layer colors are
    set explicitly, they can't be changed and they may turn out illegible against dark or bright backgrounds.
    While traditional color-less fonts
    can be colored in design apps or CSS, a black color definition in a COLRv0
    font actually means that that layer will be rendered in black regardless of the
    background color. This leads to text becoming invisible against a dark background,
    for instance when using a dark theme in a web browser or operating system.

    This check ensures that layer colors are at least 10% bright and at most 90% bright, when not 
    already set to the current color (0xFFFF).

To Do

• update CHANGELOG.md
• wait for all checks to pass
• request a review

[felipesanches]

All good, except for a bad URL on proposal field.

[felipesanches]

This URL must be fixed.

[felipesanches]

Don't worry. I'm fixing it myself right now.

[anthrotype]

This whole check is misguided and confusing (what's "color brightness" anyway, how's that defined?) -- there's two problems:

1. whether black or white end up being illegible depends on the background, and CPAL version 1 allows specific palettes to be designed for dark or light backgrounds; besides, CPAL can contain more than one palette; this check completely ignores that, just takes the first default palette, assuming it's the only one, and simply goes about complaining that some glyphs are "too dark or too bright" (verbatim). But it's wrong to assume that a given palette entry index maps to only one given color, as there could be several palettes, and some may intentionally be designed for light/dark background.
2. the check only considers this to be a problem for COLR version 0; why not also COLR version 1? How's that different from the former in the need to "not be too dark or too bright"? I'm pointing this out not much to recommend you include COLR version 1 in this check as well, but to highlight its arbitrariness.

FWIW, I would just remove this check altogether and remind designers about the possibility of using the 0xFFFF special foreground color palette entry index somewhere else (e.g. documentation about creating color fonts).