"Can't be displayed" is undefined

[svgeesus]

Originally posted over here.

In section the color function

The color function takes one or more comma-separated arguments, with each argument specifying a color, and later colors acting as "fallback" if an earlier color can’t be displayed (for example, if the colorspace it specifies hasn’t been loaded yet).

can't be displayed is undefined except for an illustrative, parenthetical example.

[svgeesus]

Not clear whether can't be displayed and invalid color are intended to be identical.

The color() function represents the color specified by the first of its arguments that represent a valid color
(that is, the first argument that isn’t an invalid color). If all of its arguments represent invalid colors, color() represents opaque black.

invalid color links to itself and is not actually defined, either :)

[LeaVerou]

I think it’s far more useful if the fallback is used for out of gamut colors as well.
Now another thing to decide is what happens when the color refers to an invalid color space (one that has not loaded yet, or not specified at all) if there’s no fallback. Does it get treated as an invalid value and cascade?

[svgeesus]

what happens when the color refers to an invalid color space (one that has not loaded yet, or not specified at all) if there’s no fallback. Does it get treated as an invalid value and cascade?

The spec says:

If all of its arguments represent invalid colors, color() represents opaque black.

so it has a resolved value and does not cascade.

[svgeesus]

So I'm tending towards:

1. Defining invalid (incorrect syntax, unfetched profile, and so on)
2. Defining out of gamut
3. Making can't be displayed the union of invalid and out of gamut

This means that operations such as color mixing can still be performed, if desired, on out of gamut colors, while making the color() fallback more useful

[faceless2]

Oh no. I've just realised my brain didn't fully engage with my final comment on #5045.

• color(foo 0 0 1) is in gamut because all the components are in the range 0..1
• color(foo 0 0 2) is out of gamut because one of the components is not in the range 0..1

For some reason I was imagining maths here, but of course testing whether a color is in the gamut of it's own colorspace is just a trivial test to see if all components are in the range 0..1. Deciding whether a color() with a component value of "2" is invalid, or valid-but-out-of-gamut is largely academic, as it has the same result. Sorry, not sure how I missed that!

Chris, in #5045 you also mentioned that ensuring TAC (total area coverage) does not exceed the maximum for an additive colorspace would also be part of the in-gamut test. This might be more problematic - first because I don't believe the TAC limit is stored in the ICC profile, second because "registration black", where all the inks are at 100% (e.g. color(fogra39 1 1 1 1)) is sometimes used in print (for printer marks in the page margins). If the color() function consider this out-of-gamut and fell back to the alternative color, it would be a problem.

[LeaVerou]

Indeed, I remember using black with all inks at 100% quite a few times when working with print. In general, I think involving TAC in this is unlikely to be helpful. The color is still in gamut after all, whether the paper survives it or not :)

[tabatkins]

Oof, yeah, I really didn't define that well enough. I think I didn't intend for out-of-gamut to do anything special here; the fallback was just for color-spaces that haven't loaded and such.

That said, it sounds reasonable to me to make it also mean "not in the output gamut".

If we do that, tho, we still want to distinguish between "out of gamut" and straight up "invalid"; we don't want to resolve color() to transparent black just because the last color in its list was out-of-gamut! Instead we want to try and render that color, using the existing gamut-correction stuff that we'd do with anything else.

So yeah, the logic then becomes:

• if the specified color is decodeable and in-gamut, use it.
• if the specified color is decodeable and out-of-gamut, attempt to use the fallback. If the fallback is an invalid color, instead use the specified color anyway.
• if the specified color isn't decodeable, use the fallback. (If the fallback ends up being invalid too, that's fine, it'll just make the outer function an invalid color too.)

[svgeesus]

@faceless thanks for your comments, I left TAC out of the definition.

[tabatkins]

@svgeesus, I don't see how the commit does what you want. The specific bit of text describing the fallback is

The ''color()'' function represents the color
specified by the first of its arguments that represent a valid color

Which doesn't invoke anything about out-of-gamut colors. "can't be displayed" is only referenced in the intro describing the function.