Bug 12205 - Add support for CMYK for css colors
Summary: Add support for CMYK for css colors
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: CSS (show other bugs)
Version: 420+
Hardware: Macintosh OS X 10.4
: P2 Enhancement
Assignee: Nobody
Depends on:
Reported: 2007-01-10 15:33 PST by Sam Weinig
Modified: 2012-02-02 08:24 PST (History)
4 users (show)

See Also:

first stab (64.59 KB, patch)
2007-01-10 16:12 PST, Sam Weinig
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Sam Weinig 2007-01-10 15:33:30 PST
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).
Comment 1 Dave Hyatt 2007-01-10 15:49:13 PST
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.
Comment 2 Nicholas Shanks 2007-01-10 16:06:47 PST
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.
Comment 3 Dave Hyatt 2007-01-10 16:09:46 PST
I don't think there's any point in adding this feature at this time then.
Comment 4 Sam Weinig 2007-01-10 16:12:08 PST
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.
Comment 5 Sam Weinig 2007-01-10 16:14:52 PST
Hm, this whole conversation took place while I was preparing the patch.  I guess I'll clear the review flag for the time being.
Comment 6 Nicholas Shanks 2007-01-12 06:38:11 PST
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 

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]
Comment 7 Alexey Proskuryakov 2007-01-12 14:43:12 PST
(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.
Comment 8 Tom Taylor 2012-02-02 08:24:04 PST
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.