W3C home > Mailing lists > Public > public-css-archive@w3.org > November 2019

Re: [csswg-drafts] [css-color] Generic Transform Function for RGB Color Spaces (#4488)

From: Mike Bremford via GitHub <sysbot+gh@w3.org>
Date: Wed, 13 Nov 2019 22:09:40 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-553627517-1573682979-sysbot+gh@w3.org>
Using an ICC profile to do the conversion is an implementation decision, of course. My reply was mainly in reply to Crissov's second post, not his first - I don't think that adding `composition`, `white-point`, `linearization` as property values to `@color-profile` is useful. I've no issue with including the definitions of those spaces in the spec.

* I believe the concerns about DeviceN not being a colorimetric specification are unfounded. Provided each separation has a "fallback" value defined in a process colorspace such as `device-cmyk`, sRGB or an RGB/CMYK ICC space, they can be converted to that for blending. That's how they're defined in PDF and PostScript, and any PDF viewer that displays a PDF on screen has to do this already.

I outlined one such algorithm at the bottom of #2023, along with a demonstration showing how it could be defined in CSS and document showing the result. If you think this approach has legs I'm happy to flesh this issue out, or open  a new one without the considerable cruft of my earlier comments - as you prefer.

* Regarding opacity, SVG filters etc., these are currently defined in the spec as requiring conversion to RGBA first. I'm not proposing changing this, as I know full well the horrors this would lead to.

* Regarding "knock-out" - I understand this term to describe the current rendering model, where drawing red over blue (or cyan over black) replaces the background color completely. The opposite being "overprint", where inks not present in the current colorspace are unchanged. This only makes sense with additive color and is not supported in CSS, although again Prince, AH and RealObjects all support it via a non-standard property. Is that what you're getting at?

I'm very much aware of the difficulty in rendering overprint on screen - we have a PDF to bitmap converter and don't currently support it when rasterizing, as it requires keeping track of each individual color separation. I certainly don't expect browser engines to support this rendering model. As none of the suggestions so far preclude adding later support for it, I'd be inclined to kick it down the road and deal with it later myself.

GitHub Notification of comment by faceless2
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4488#issuecomment-553627517 using your GitHub account
Received on Wednesday, 13 November 2019 22:09:42 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:56 UTC