[csswg-drafts] [css-color] "device-cmyk" restrictions are counter-productive

faceless2 has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-color] "device-cmyk" restrictions are counter-productive ==
I think the way device-cmyk is defined could be improved. I note there is a comment in the current draft:

> RESOLVED: If you accurately describe the output device’s color profile in an @color-profile rule then a sane implementation will not alter your colors so this is sufficient as a replacement for device-cmyk in general and provides a good RGB fallback automatically.

Which seems to be missing some detail about this process, and still makes some assumptions about the implementation.

Currently the author of a CSS stylesheet wanting to use CMYK has three choices.

1. Abandon device-dependent CMYK and always specify CMYK with color() and an ICC profile
2. Use device-cmyk() but define a corresponding RGB (or convertable-to-rgb) value as a fallback color (effectively doing the job of an ICC profile themselves)
2. Use device-cmyk() and hope the _"...user agent has information about the output device such that it believes it can accurately convert the CMYK color to a correct RGB color..."_, and if not, make do with the CMYK to RGB conversion of the "naive CMYK" colorspace. A space which resembles no real-world device.

This wording is quite restrictive; if I am opening the file in a typical web browser, I don't have any particular information about a CMYK output device, so am required to use the naive colorspace. There is no middle-option, where the user-agent (or CSS author) may choose a typical profile, on the understanding it may be substituted when output to a particular CMYK device.

Device-dependent CMYK color is important; not every workflow is calibrated, and not every document author knows the target device. But even without any specific target device in mind results should resemble a typical printer, which the naive conversion does not.

This can be achieved with more flexibility, and less user-agent restrictions or magic, by changing the way the fallback is calculated. Something like:

> If a CMYK color is specified and the user agent can natively output CMYK, the CMYK values should be used exactly as specified. Otherwise, if no fallback color is defined, the "device-cmyk" @color-profile will be used to convert to RGB. If no "device-cmyk" @color-profile" is defined, or it is defined but is not a CMYK ICC profile, then the naive conversion is used.


This removes the restrictions (and implied magic) about the user-agent having information about the output device. Instead, a user-agent might define something like

````@color-profile device-cmyk { src: url(swop.icc) }````

in the user-agent stylesheet as a reasonable default. The CSS author doesn't care and simply defines

````color: device-cmyk(100% 80% 50% 0)````

in their stylesheet, knowing that most user agents have a reasonable default and the naive conversion is unlikely to occur; and the user displaying the CSS, if print-previewing for a specific device, can override this by specifying a user-stylesheet with

````@color-profile device-cmyk { src: url(myprinter.icc); }````

Effectively **device-cmyk(c m y k)** is now identical to **color(device-cmyk c m y k)**, but with two provisions: that any "device-cmyk" @color-profile rule is ignored if the device can natively output CMYK, and that the naive colorspace will be used if no "device-cmyk" @color-profile rule exists.


Finally, it may be that what I'm describing is largely what the aforementioned "sane implementation" is supposed to do for _any_ CMYK profile specified - it's not clear from the "RESOLVED" section from the spec quoted at the top of this post, and I cannot find discussion of this point.

If so I'm not sure that's wise. A device-independent, ICC based colorspace defined by the document author should not be ignored in a color managed workflow, sane or otherwise; it should be preserved all the way through to conversion to PDF (our area of expertise) or when printing. This is very distinct from an unmanaged CMYK space. There is no need at all for that distinction to be discarded.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2022 using your GitHub account

Received on Friday, 1 December 2017 12:33:11 UTC