W3C home > Mailing lists > Public > public-css-archive@w3.org > March 2020

Re: [csswg-drafts] [css-color] "device-cmyk" restrictions are counter-productive (#2022)

From: Chris Lilley via GitHub <sysbot+gh@w3.org>
Date: Wed, 18 Mar 2020 22:23:39 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-600888936-1584570218-sysbot+gh@w3.org>
> My only real concern is this requirement to use the "naive algorithm" for rendering. It will result in authors avoiding device-cmyk, because it looks awful when previewed in a browser.

Mine too. I'm wanting to reword so that the naive conversion is used as little as possible, only after other things have gone wrong.

Related, I worked yesterday on an example for the spec. I took the Lab values for the Macbeth color checker, converted them to sRGB (for two patches, I had to go to LCH then reduce C until the result was inside sRGB gamut). Then I am also running the Lab values through a CMYK profile (PSOcoated_v3 from ECI, which uses the FOGRA51 characterization data) then naively converting the CMYK to sRGB. This shows the magnitude of the error on some real-world colors.

> With two years of hindsight on this issue, I think simply allowing browsers to choose an arbitrary profile for device-cmyk, instead of being forced to use the naive algorithm, is the best solution. Yes, it will make the results vary from browser to browser - that's what you'd expect from device-dependent CMYK.

Agreed.

-- 
GitHub Notification of comment by svgeesus
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2022#issuecomment-600888936 using your GitHub account
Received on Wednesday, 18 March 2020 22:23:41 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:42:02 UTC