[Openicc] Printing Plans GhostScript

[Chris Murphy]

On Mar 1, 2011, at 3:19 PM, Kai-Uwe Behrmann wrote:
> 
> What I do not understand is, how can Mac OS be opt-out and Microsoft be
> opt-in when both be in parity?

My statement was not entirely qualified. So it is a fair question.

They are in parity in the singular context of how printing works by default. Both Mac OS and Windows print drivers assume incoming RGB data is sRGB. For PostScript CMYK, again, there is parity because both OS's use pass through for PostScript CMYK. I'm a little sketchy on how RGB PostScript is handled because that is quite rare on those platforms. Usually RGB printing uses Quickdraw (legacy Mac OS), Quartz (present Mac OS), or GDI on Windows.

Where they are NOT in parity: Windows applications that do not opt-into ICM have all ICC profiles stripped, print drivers don't use those profiles either, and sRGB is assumed by default as the incoming source space.

The print drivers on Mac OS are able to ask for what the hand off color space is. It just so happens to be sRGB by default, and for most drivers is only sRGB because they don't even specify. So Mac OS assumes sRGB for source and destination, hence no conversion, but the print driver does assume sRGB. But it's possible that the driver asks for Adobe RGB, or the application tags its data with something other than sRGB: in that case ColorSync normalizes to make sure the data is in the driver's requested hand off space, even if the application doesn't ask ColorSync to do it, and even if the user didn't choose ColorSync in the print dialog.


> 
> I tent to understand that the Microsoft way does the same like osX just without ICC profiles. That leads me to the next question, is on Windows sRGB the largest possible gamut for RGB printing?

By default, yes. But same for Mac OS. A Windows application can submit tagged data through ICM for printing, and then the user can choose ICM in the print driver dialog to choose a printer ICC profile instead of driver (default) proprietary color management. In this case ICM can do a source to destination conversion that does not use sRGB as an intermediate space.


> Would this affect as well ICCbased PDF's?

Depends on the PDF viewer and its ability to do handoff or prematching. Windows doesn't use PDF based print spools, they are GDI or XPS based.

> And if the driver is responsible to behave like sRGB, then we have the burden of some sort of colour management inside the driver and not in one place inside one ICC profile.

Correct.

Keep in mind by default on Mac OS and Windows for printing, ICC based color management isn't really being used. Both platforms depend on the printer manufacturer supplying black box print drivers that assume some source space (usually sRGB) and internally converting that with proprietary tables. That's the better than 90% use case scenario on both platforms. We're talking about hundreds of millions of users who use these workflows and are generally satisfied. That does not mean no room for improvement, but improvement is not simply done. And the merit of this existing paradigm is that it is really quite simple for the quality you do get. Not perfect but it isn't all just about color.

But it's amusing that it's not ICC based. There's no reason why we couldn't have parity with default ColorSync and ICM solution instead of driver proprietary color. It's just that the manufacturers appear to prefer a black box to do conversions in the driver rather than with ICC profiles in advance of the driver, for whatever reason.


Chris Murphy