[Openicc] Printing Plans GhostScript / sRGB / ICC

[Kai-Uwe Behrmann]

Am 04.03.2011 03:36, schrieb Chris Murphy:
> On Mar 3, 2011, at 3:04 PM, James Cloos wrote:
>> The nearest PPD to me has:
>>
>>    Image RGB Source:    None *sRGB AdobeRGB AppleRGB ColorMatch baRGB
>>    Image RGB Intent:    Business *Picture Proof Match
>>    Text RGB Source:     None *sRGB AdobeRGB AppleRGB ColorMatch baRGB
>>    Text RGB Intent:     *Business Picture Proof Match
>>    Graphics RGB Source: None *sRGB AdobeRGB AppleRGB ColorMatch baRGB
>>    Graphics RGB Intent: *Business Picture Proof Match

The intention appears to me coming from Michaels announcement to support
different default colour spaces for various graphics elements in
Ghostscript. This concept tries to utilise the DeviceRGB without
OutputIntent automatic colour management. It is in some way dangerous as
it puts smartness at a very high level into a basically non colour
managed workflow. That makes live too easy for all those lazy people,
who do not care about colour management. Instead colour management
should be made easier than to ignore it.

James seems like he wants to expose the Ghostscript options inside (G)UIs.

The idea of separating colour spaces per object type is great and, I
guess, pretty common in print business. It would be great, if we can
come up with a recommendation on, how to best get text printed with pure
black, while images are printed with all colour inks.

> 1. Are these options going to appear in the GUI? Can they be ignored or turned off somehow? I really think we need a way to force their deprecation.

I tent to agree with not showing such advanced stuff by default to
innocent users. This would be a specialised feature.

> 2. For RGB, is there really, at the present time, any source more applicable than sRGB for untagged objects? I say no (specifically, not yet defined). What does everybody else think?
>
> a. If it's untagged but not sRGB:
> 	i. How could or why should the user possibly know this?
> 	ii. Why is it untagged? Was it never tagged to begin with, or did something else in the pipeline strip it? Why?
> 	iii. Why would I be limited to this list of RGB? For it to have *any* purpose it would have to be capable of listing every possible RGB space.
>
> I don't know that I need to go on how completely inapplicable it is for an end user to define the source space for untagged RGB. If we're going to be putting kludges into PPDs because something upstream isn't working, we're going to have a really fakaked and kludgy color management system (and PPDs) once all is said and done.
>
> 3. Why and how could there possibly be different sources for text, images and vector graphics? This makes less sense than the very option of choosing color spaces, unless of course, it is anticipating the existence and acceptance of malevolent applications that ignorantly strip ICC profile metadata.

It appears to come from the legitimate wish, to print text with pure
black and not with any other colour channels involved.

> 4. So what gets used? What the user chooses in the print dialog from the pop-ups that this portion of the PPD generates? Or what the user has chosen elsewhere in their applications, or in the Gnome Color Manager or Oyranos or whatever their ancestors are? How many different locations do we really need for users to set default color spaces for untagged objects?

I have the feeling we discuss about the right problem to solve in a
difficult place. Anyway, its a interesting problem.

>>
>> That pdd also supports a simulation profile for DeviceCMYK:
>>
>>    Simulation Profile: None *SWOP Euroscale Commercial DIC TOYO
> This is annoying and nonsensical also, but there's probably not a lot that can be done about it in a v1.0 or short term. This is a relic of a bygone era. And how it works varies from printer to printer. So preventing it from happening, and then rolling better conversions (even default ones) within a new framework which would achieve better consistency from device to device, is a long shot. By default, this means there is no such thing as /DeviceCMYK on this printer. An internal conversion will occur. It expects to receive SWOP, and usually such a system has *NO MEANS* of communicating this expectation upstream so the data can be properly submitted every time.

Proofing belongs either into the applications or, at the moment, into a
hand crafted xxxtoraster filter.
Too many might loose overview if we try to put all bells and whistles
into v1.0. We are already very busy on discussing the very basics and
how to get that v1.0 working including naming and working on bugs.

kind regards
Kai-Uwe