- From: Mike Bremford via GitHub <sysbot+gh@w3.org>
- Date: Thu, 11 Jun 2020 09:54:59 +0000
- To: public-css-archive@w3.org
That's an interesting proposal. On my to-do list was filing an issue on the `rendering-intent` property which can currently be specified as part of a `@color-profile` rule. The problem is that it sets the intent for the color-space as a whole, but that's not how I expect it will be used (if it's used at all, which quite frankly I'm doubtful of). For example, if I'm drawing a gradient in CMYK, I may want to use "perceptual" intent, but if I then want to do some block colors in the same colorspace, say for a barchart, I'd want to use "saturation". So the `rendering-intent` really needs to be specified on the element, not on the color-profile. It's of such limited applicability for browsers (only applying if the color they need to convert to their display colorspace is specified in an ICC profile with A2Bn tables, i.e. a CMYK profile) that I expect browser vendors can get away with ignoring it completely. For the CSS-to-PDF vendors, the rendering intent is applied to an individual drawing operation, not the color-space as a whole, so this is a more natural fit. So hopefully promoting it from the @color-profile rule to a regular property will make next to no difference for anyone. Anyway, the point I came here to make was that if you're going to do this, and also need to define some sort of gamut-mapping function, it might not be a bad idea to roll it into the same property. So, for example, your element could have `rendering-intent: saturation` to use the saturation tables in the ICC profiles if available, or `rendering-intent: whizzy-lch-function` to use whatever @svgeesus digs up. -- GitHub Notification of comment by faceless2 Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5191#issuecomment-642542435 using your GitHub account
Received on Thursday, 11 June 2020 09:55:00 UTC