[Printing-architecture] Common Printing Dialog and color management

Chris Murphy lists at colorremedies.com
Thu Feb 24 14:27:49 PST 2011

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

> On 24 February 2011 21:42, Chris Murphy <lists at colorremedies.com> wrote:
>> In that case you either have to fail the print job, or you have to assume some CMYK space
> So, in the case of CYMK, it's not just as case where we can "assume
> sRGB" like we can RGB with a clear conscience. It kinda comes back to
> my original question, is this a per-user preference, or a per-system
> policy?

Ha it's a per instance preference. The document should be self describing (tagged) to prevent this event from being questionable in the first place. In my view any application that lets a user work on CMYK that does not tag its own data is asking for trouble - by rights CMYK print jobs going to non-CMYK devices should fail. But that's not such a great sort of degradation for users.

Apple and Microsoft require applications to honor conversion to RGB on demand - i.e. the system knows the driver being selected is RGB at the time the dialog pops up and the printer is chosen and the system informs and requires the application submit RGB at the time the job is spooled. So that makes conversion the responsibility of the application. Not the system. I tend to agree with this strategy.

Farther downstream, I would think GhostScript has some assumption it uses when incoming file is CMYK and outgoing file must be RGB (or vice versa). I don't know presently where this logic is handled.

If you're going to have some system level service handle this correction, well you have various points where that could occur and if you're really going to build such a thing, you might consider including spot color and DeviceN into the plan so that, even if you don't build in such support now, you don't have an "oh shit" later on when you find the location where this is handled in the print pipeline is not ideal. Ideal would mean downstream from the app, but upstream from rasterizing, but downstream enough to know the capabilities of the printer, even in fact how well it registers colors is a nice bit of info to have when properly building device values for print.


More information about the Printing-architecture mailing list