color_cpal_brightness check is misguided and confusing

[felipesanches]

Cosimo said:

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

Originally posted by @anthrotype in #3908 (comment)

[felipesanches]

@yanone, what do you think?

[yanone]

I think checks exist to make the life of us font onboarders easier and catch mistakes to improve font quality. That's kind of the purpose of fontbakery in my understanding. The amount of issues one needs to keep in mind is ever increasing in an ever developing and diversifying font technology world.

Cairo Play was onboarded with glyphs being painted in black instead of the foreground color. Rod did find and correct this before publishing, but I didn't, and neither did I even know about this at the time, nor did its author. Today I know about it, but our work is stressful, so I can't guarantee to remember this next time. Personally I believe black should be a FAIL and be ingored for a false positive, not just a WARN, but Dave thinks otherwise, so what can I do.

This Github issue here is now the third time that it is being discussed that Cosimo strongly objects to a conduct in a repository that he's not involved in, even after admitting that fontbakery is for font onboarders and that you are maintaining it, not him.

So from a work efficiency perspective I've now spent more time and nerves arguing about this with you and Cosimo than I've spent writing the check, so I'd be happier if you would just delete the PR and I and the entire rest of the world try to remember next time to check manually that color fonts look good on all types of background.

What started out as the innocent attempt to improve our work is now haunting me to the point where I wish I hadn't done this, and where I wish that this issue won't harm my pleas to improve other repositories that Cosimo is involved in because there's a whole set of issues piled up.

From a font QA perspective, I strongly wish this check would remain. However, downgrading the check to WARN has already watered down the usefulness to near-zero because I almost never look at WARNs, especially not under stress. Cosimo is right in saying that an explicitly painted black (or white) isn't necessarily a mistake. I say that I'm intelligent enough to assess what is a mistake and what isn't, and so will other onboarders. It's highly irritating to me that this needs to be discussed again even tho the check is a WARN only, and it only gets more irritating that you had to make a separate issue for this instead of just asking me in the PR where Cosimo commented.

I just don't see the problem. So really, just delete it. It's already useless as a WARN.

What comes to mind as a solution instead is that we could involve @m4rc1e to include a special HTML rendering as part of gftools qa to render a special color fonts check once in white on black and once in black on white to check visually whether letters disappear, but it's a bit more difficult because glyphs can be painted in any combination of colors and you need to catch all relevant glyphs in the HTML rendering, which the check did programmatically for all glyphs.

But I guess since we rely on a mixed-purpose text for the browser previews already, the whole page could simply be inverted in color at the press of a button.

[RosaWagner]

I agree with Yanone this check should remain. Nothing is forced onto people for their own foundry and non-googlefonts project here. This check doesn't even enforce anything for GF, it is just to remind us to check about potential problem with color fonts background we may not think about using dark mode — which is needed by other onboarders who doesn't know anything about color fonts (for eg. me)

[m4rc1e]

I'm a total colr font numpy so forgive me if this is a stupid question, can a layout engine detect that a colr font is being used on a dark background or does the user need to modify the CPAL themselves?

[yanone]

I was gonna comment on this topic earlier but discarded: The palettes in CPAL can have a flag that can be set for whether a palette is designed for a light or dark environment. But Glyphs doesn't implement this yet, so we’re not expecting to see that flag around any time soon in my opinion. For now, the palettes are random. I hope that answers your question.

I think we should render the font in white on black and black on white with the default palette to see whether one of the two looks off.

[anthrotype]

This check is at the same time too broad (warns about COLRv0 font whose CPAL contains "almost" black or "almost" white in the first palette) and too narrow (only assumes one palette, doesn't take into account explicit light/dark palette flags, doesn't check COLRv1), so I think it will produce so many false positive and false negative to become meaningless. I didn't mean to be a troll, was just trying to help. And I don't see how this issue may "harm" Yanone's contributions to other libraries that I maintain, no need to take this personal. Definitely do keep the check if you think it helps, just be aware of the above limitations.

[yanone]

As soon as Glyphs implements the flag in its UI, I would indeed update the check. Everything is work in progress.

[davelab6]

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).
I think it will produce so many false positive and false negative to become meaningless

False results are still helpful for users who don't read our docs end to end, keep it all in their head, but do look into things they are WARNed about by their fontbakery report :)

I think @yanone has done good work with this check.

Glyphs doesn't implement this yet, so we’re not expecting to see that flag around

We can set the flag with fonttools post-fontmake scripts though, so I recommend to have the check assume this is in use, and to also WARN when it isn't, since color fonts should make use of this flag.