Bug 12205 – Add support for CMYK for css colors

• Status: NEW
• Component: CSS

[Sam Weinig]

This enhancement would add support for two css values -webkit-cmyk() and -webkit-cmyka() which can be used anywhere a css color value is used (ie. color: foo;, background-color: bar;).  It would work exactly the same as the hsl() and hsla() values work.  There is no spec for this, but Prince6 alpha supports it (http://www.princexml.com/howcome/2006/p6/p6demo2.html).

[Dave Hyatt]

I would leave -webkit- off if you add this.  It's so obvious what the syntax would be that I'm not concerned about it shifting if it became standardized.

[Nicholas Shanks]

The problems with leaving off -webkit- are these:

1) The CMYK to RGB algorithm used at present may be subtally incorrect in ways that matter. if it's wrong and a developer does something like:
color: rgb(x,y,z);
color: cmyk(a,b,c,d);
expecting UAs that don't support cmyk() to use the closest RGB approximation in the prior declaration, and we don't, we've got a problem.

2) The only syntax sample is that prince6 page, it seems to indicate that 0.0 is the minimum and 1.0 is the maximum. What if they change their implementation to 0 to 255? then would "1" be bright or dark?

Until these can be resolved, I recommend leaving the -webkit- prefix on.

[Dave Hyatt]

I don't think there's any point in adding this feature at this time then.

[Sam Weinig]

Created attachment 12352 [details]
first stab

This patch adds support for both cmyk and cmyka.  NOTE: the algorithm used may not be the best possible algorithm as it's conversions don't match the conversions done by the Apple Color Picker.

[Sam Weinig]

Hm, this whole conversation took place while I was preparing the patch.  I guess I'll clear the review flag for the time being.

[Nicholas Shanks]

A reply from Håkon:


> Could you provide any details on the CMYK to RGB algorithm prince uses?

We don't convert CMYK to RGB at all, we embed the CMYK colors directly 
in the PDF file as-is. That is the only reason we bothered to add 
support for the cmyk() function: so that authors could specify 
exactly which CMYK color they wanted and have that carry through to the 
printed output (a customer requested this functionality).

[this must be done by PDF then can we find their algorithm? -- Nicholas]

> And what are acceptable parameters for the cmyk() function? Percentages 
too?

We accept either four numbers between 0 and 1 or four percentages. We 
don't support mixing numbers and percentages, as the rgb() function does 
not support this.

I don't think that 0..255 makes sense for cmyk(), as there is no 
tradition of representing CMYK colors as a tuple of 8-bit values as far 
as I know, whereas there is for RGB colors.

Note that the CSS3 Color module is not entirely consistent in that HSL 
colors (which Prince does not support) specify the saturation and 
lightness components only with percentages, not numbers at all. However, 
RGBA colors specify the alpha value only as a number between 0 and 1, 
even though it would seem to make sense to also allow a percentage to 
specify the alpha.

[so it seems we should add percentage support but not 0-255, which resolves that issue -- Nicholas]

[Alexey Proskuryakov]

(In reply to comment #6)

> [this must be done by PDF then can we find their algorithm? -- Nicholas]

"PDF" doesn't have an algorithm for this, PDF rasterizers do. Any decent one will utilize a CMM, such as ColorSync, respecting embedded and device profiles.

Sounds like there isn't much point in implementing cmyk() without ensuring that it reaches printed output untangled.

[Tom Taylor]

Just to say, having native CMYK colors would be fantastic. When combined with CSS Regions and hyphenation + ligature support it would make it possible to do complex layout and typography for print in browser.

Does anyone have an idea how much effort might be required to add this? It might be something I could find some sponsorship for.