Summary: | Add support for CMYK for css colors | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Sam Weinig <sam> | ||||
Component: | CSS | Assignee: | Nobody <webkit-unassigned> | ||||
Status: | NEW --- | ||||||
Severity: | Enhancement | CC: | ap, nickshanks, services, tonikitoo | ||||
Priority: | P2 | ||||||
Version: | 420+ | ||||||
Hardware: | Mac | ||||||
OS: | OS X 10.4 | ||||||
Attachments: |
|
Description
Sam Weinig
2007-01-10 15:33:30 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. 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. I don't think there's any point in adding this feature at this time then. 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.
Hm, this whole conversation took place while I was preparing the patch. I guess I'll clear the review flag for the time being. 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] (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. 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. |