[Printing-architecture] Common Printing Dialog and color management

Chris Murphy lists at colorremedies.com
Thu Feb 24 14:51:41 PST 2011

On Feb 24, 2011, at 3:43 PM, Richard Hughes wrote:

> On 24 February 2011 22:27, Chris Murphy <lists at colorremedies.com> wrote:
>> In my view any application that lets a user work on CMYK that does not tag its own data is asking for trouble
> Isn't any app capable of outputting CMYK going to ask the user for an
> embedded profile? Outputting CMYK is a pretty power-user feature, and
> unspecified CMYK isn't really anything useful at all.

Unknown / not necessarily. It's only been in the last few years that Photoshop started embedding ICC profiles in CMYK images by default. It is common in prepress (usually due to emotionally unstable reasons) to strip CMYK profiles from images and save them untagged.

How they became CMYK? Well they can get there by creating a CMYK illustration file from scratch and designing in CMYK. No conversion to CMYK actually occurred. But yes, to display that CMYK image/illustration on an RGB device implies some kind of transform. Whether it's ICC based or not...usually that would be the case. But historically developers have simply used inversion. 100%C is 0%R (100%G+100%B), etc. which gets you really overly saturated CMYK images on screen, completely not color accurate. But you can at least see what you're doing. Recent versions of QuarkXPress work this way I think still, by default. So I can't vouch for apps on Linux, how they will behave with respect to CMYK. They very well may be thinking of plotters and such and never have considered anything other than RGB for display, and therefore just used 1/d conversion.


More information about the Printing-architecture mailing list