[Openicc] Printing Plans GhostScript

[Kai-Uwe Behrmann]

Am 01.03.11, 14:49 -0700 schrieb Chris Murphy:
> The converse is that you start taking responsibility for other people's 
> mess. Both paths have consequences for users.
>
> If /DeviceRGB is going to sometimes be assumed to mean sRGB when the 
> output is RGB or CMYK, then we immediately need some way to communicate 
> "pass through" that is not in the PDF or CUPS specs. So that is why I 
> suggested this need should be brought up with those who code the CUPS 
> filters and Ghostscript because those items are the ones that need to 
> understand the new token.
>
> If you're going to second guess /DeviceRGB, then it's inherently a more 
> complicated implementation that needs to be created, because now it's 
> opt-out. Not opt-in.

true

> In opt-out (meaning, color management happens unless the application 
> opts out):
>
> If the application is *dumb* then that means it also has no ability to generate a pass through token. The PDF or PS spool from such an application arrives at: pdftopdf, pdftops, pstops, pstopdf filters, where /DeviceRGB, /DeviceGray, /DeviceCMYK stamped out of it in favor of specific spaces. [While I include PostScript here for completeness, I'm personally in favor of ignoring stupid PostScript devices whose PPDs make unclear how the PostScript should be formed.]  I suggest doing this with CUPS prefilters because I don't think it's necessarily a good idea to compel Ghostscript to make these assumptions. If they are in prefilters, those assumptions are possibly easier to change, but again this is a question for those who are responsible for these pieces. If it doesn't happen in CUPS filters, then it must happen in GhostScript which means Ghostscript needs to understand the pass through token.
>
> If the application is smart, then it should properly tag all objects. Anything that is /DevicexxxX would need an additional token to inform the downstream piece that in fact /DevicexxxX designation should stay intact and not substituted with default source spaces. This token could be singular, applies to the whole document meaning "any instance of /DevicexxxX should remain as such". Or the token is per object. I think once is sufficient, I don't see a use case for even allowing mixed mode untagged content.
>
> In opt-in (meaning, color management only happens if the application requests it):
>
> Then you only have smart apps. Dumb apps always produce "pass through" spool files.
>
>
> Mac OS today is opt-out. On Mac OS, you need a pretty smart application to opt-out. While we can make this more stable than Mac OS is, it's still something that has to be designed: that pass through "token" in the spool file.
>
> Windows today is opt-in. Windows gets away with it because they've told all of their ISV's that untagged incoming RGB is to be treated as sRGB. And this has been replicated on Mac OS by default as well. So the default behavior on the two platforms is in parity. The Windows opt-in paradigm is proven to be more reliable for professionals who build custom profiles, because they only need applications that are dumb to ensure a pass through, no special token is needed.

A interessting comparision.

> For the vast majority of consumers, I think it's a stretch to propose that the Microsoft sRGB paradigm is inadequate.

What I do not understand is, how can Mac OS be opt-out and Microsoft be
opt-in when both be in parity?

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?
Would this affect as well ICCbased PDF's?
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.

> Chris

kind regards
Kai-Uwe Behrmann
-- 
developing for colour management 
www.behrmann.name + www.oyranos.org