Re: [csswg-drafts] [css-color] Separation / DeviceN color support (#2023)

Thanks for looking at this Chris!

> how would they be written with the same duotone but if you had the actual spot inks, rather than process-color equivalents?

You mean the HTML example from blue to red? So if it was defined instead as something a bit like this?
```css
@color-profile --duotone {
    components: "PANTONE Reflex Blue C", "PANTONE Warm Red C"
}

or even

@color-profile duotone {
    components: color(--reflex-blue, 1), color(--warm-red, 1);
}

```
Currently I'm not proposing that at all.  I would suggest that a "_custom color-profile_" is defined by reference to another color-profile which _must_ be a process color-profile:  device-cmyk, an ICC profile, or (mathematically possible, but with no practical purpose) RGB or Lab.

We did experiment with a syntax like the above but rejected it in the end:

1. It's more complicated. Allowing a color-profile to somehow reference or build upon another color-profile means you need loop detection, dynamically updating when a profile loads is more complex, you need to reject invalid combinations etc.

2. PDF is likely to be the only target media that doesn't immediately collapse these to RGB, and PDF requires that a) the inks defined in any custom color-profile are defined using process colors, and b) that the same color-profile is use for all inks. The syntax I proposed reflects this.

Consider if you had a syntax like the example earlier in this comment, and "reflex blue" is defined against device-cmyk and "warm red" was defined against FOGRA 39. Well, you're stuck: the only way to proceed without error is silently convert them to be in the same space.

It's more of a problem if you're defining a duotone from a spot color to a process color, eg. black, especially when you consider the cascade:
```css
/*
Define "warm red" twice - first in device-cmyk, and then in our chosen
FORGRA39 profile. If the latter is not available, we'll fall back to the former.
*/
@color-profile -warm-red {
  src: device-cmyk;
  components: "PANTONE Warm Red C" 0 0.75 0.9 0;
}
@color-profile -warm-red {
  src: url(fogra39.icc);
  components: "PANTONE Warm Red C" 0 0.76 0.9 0.01;
}

/* Now define a duotone from black to the "warm red" we defined above. */
@color-profile duotone {
  components: black, color(--warm-red, 1); /* Nope! black is sRGB */
  components: device-cmyk(0 0 0 1), color(--warm-red, 1); /* Tsk, presuming warm-red is also device-cmyk */
}
```


Yes, it means you have to define a color twice if you're going to use it as a single spot-color and in a duotone. It's not the end of the world and variables mitigate this:
```css
:root {
    --reflex-blue: "Pantone Reflex Blue C"  1 0.723 0 0.02;
    --warm-red: "Pantone Warm Red C" 0 0.75 0.9 0;;
}
@color-profile --reflex-blue {
    src: device-cmyk;
    components: var(--reflex-blue);
}
@color-profile --warm-red {
    src: device-cmyk;
    components: var(--wam-red);
}
@color-profile --blue-red-duotone {
    src: device-cmyk;
    components: var(--reflex-blue), var(--warm-red);
}
```

Having quite a few spot colors in a document is probably quite common - business graphics, corporate colors and so on. But I would think a gradient involving a spot color, while something that should be possible, is going to be a lot less common for sure. If you have N spot colors you're not going to need to defined NxN gradients.

If you're still unconvinced let me know, and I will try and put some numbers on these statements.

I should finish by saying if there is some sort of syntactic sugar to mitigate this further I'm all for it, of course. But it shouldn't be much more than that in my opinion.

Again, thanks for looking at this. 

-- 
GitHub Notification of comment by faceless2
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2023#issuecomment-605658927 using your GitHub account

Received on Sunday, 29 March 2020 16:02:10 UTC