[css-color] Device cmyk still needed?

[svgeesus]

https://drafts.csswg.org/css-color/#cmyk-colors

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.

[frivoal]

I fully agree from a theoretical standpoint that it isn't needed.

On the other hand, it has been supported in various print-centric UAs (either as device-cmyk name or as cmyk()), and therefore there's content that depends on it and I have a bit of a hard time seeing it go away. I wonder if we should try to provide some backwards compat / upgrade path at the spec level.

[svgeesus]

Agree that there is content with cmyk(). Suspect it is not very interoperable if opacity, rgb fallback, filter effects etc are applied; this is all rather under-specifed at the moment. It would be good to do some tests on those print-centric UAs to see what they do here.

[frivoal]

I believe the print centric UAs that support cmyk will not try to combine CMYK and rgb and do color math on them, and instead will push all CMYK objects as CMYK into the pdf, and ditto for the RGB objects.

Here's a micro test: http://jsbin.com/texehe/edit?html,css,output

Prince produces this: http://florian.rivoal.net/csswg/texehe/prince-output.pdf

PDFReactor produces that: http://florian.rivoal.net/csswg/texehe/pdfreactor-output.pdf

Have fun looking into what these files contain (I don't know much about how pdfs are built, so it is better I'm not the one looking inside).

[cabanier]

Have fun looking into what these files contain (I don't know much about how pdfs are built, so it is better I'm not the one looking inside).

I inspected the content streams of these files and the colors are just passed through as-is which is what you expected.
(This does mean that these are not prepress ready files and a publishing house would reject them)

[cabanier]

I believe that deviceCMYK will always be needed.
Almost always, authors that create CMYK content, want those same ink numbers when going to print, regardless what the output profile.

[danielhjames]

Hi Rik, I agree, when working with colours in branding such as logos, we are normally working from explicit CMYK values optimised for coated or uncoated paper, i.e. the conversion from another colour model has already been made. We don't want to convert from RGB values using a profile, which requires the user to obtain and know how to use a specific profile. Where the document is public, or printed on more than one continent, we have no way of knowing which profile to embed.

[frivoal]

@danielhjames you seem to be saying something different from What @cabanier is.

Yes, authors want to input CMYK values directly, not input RGB that gets converted to CYMK. The questions is whether authors want/need to input CMYK values without specifying which CMYK that is. If you're specificying US Web Coated SWOP CMYK colors, that's different from "deviceCMYK". That's using the US Web Coated SWOP color profile.

The same CYMK values on the same type of paper will come out different on different printing presses if you do not specify which profile is assumed/used.

For "deviceCMYK" values to come out right, you need to have not only optimized for the right type of paper & coating, but also for the specific model of printer and ink you're going to be using (and possibly how it's been calibrated). Not all printers and all inks have the same color as 100% cyan. The point of a profile is to say what you color you mean when you say 100% cyan. The point of not using a profile is to explicitly ask the printer not to worry about what color you mean, and just use 100% of whatever exact color cyan is on this particular print press.

Where the document is public, or printed on more than one continent, we have no way of knowing which profile to embed.

It's the other way around: when your document is public, or printed on more than one continent, if you do not specify a profile, the printer has no way of understanding which colors you mean.

When you specify a profile, you do not specify what the printer is going to be like, you specify what your colors mean. If that setting happens to match the profile to which the printer is set, thinks will work with minimal conversions, and all is great. If it does not match, your document gets adjusted automatically, and everything is still fine. If you do not embed a profile in you file, and instead rely on implicit knownlege of which profile the printer you plan to use will interpret it as, things only come out fine if the printer is indeed set up the way you expected. Print it anywhere else, and colors will be off.

I do believe that there is some limited need for deviceCMYK, but "I don't want to send RGB that gets converted", or "I've optimized for coated" isn't it.

[danielhjames]

Hi Florian, my experience is that for specific colour matching, designers start with Pantone shades and then supply the CMYK values from either the coated or uncoated swatch, without reference to an ICC profile.

As I understand it, ICC profiles come into the matter when converting between colour models such as sRGB to CMYK. in which case we state the ICC profile in order to make it clear which paper and coating we're assuming in that conversion.

What I meant about printers in different countries is that there is little point embedding an ICC profile by default, as depending on which country the document is printed in and the machine or paper they have available there will be a fair chance it is wrong. That would imply keeping RGB sources as RGB and converting them on the fly to CMYK, depending on the profile that the user selects.

[svgeesus]

In general, the consensus seems to be that device CMYK is still needed, so leaving it in the spec.