[Openicc] Printing Plans GhostScript / sRGB / ICC

[Chris Murphy]

On Mar 6, 2011, at 11:42 PM, Graeme Gill wrote:

> Chris Murphy wrote:
>> 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
>> 
>> I'm just shaking my head...I don't have a coherent response to a PPD that
>> looks like such utter bollocks.
> 
> I'm not sure why you say that. The above is a perfectly rational way of using
> the existing printer control mechanisms (PPD's) to get a product that
> can do what 99% of what people want, including making profiles.
> It's mildly complex if you know nothing about color, but the defaults
> will do reasonable things for most people, particularly in a home
> or office context.

Response 1: The *default* is doing what 99% of what people want. The None option is doing what 1% want, and maybe another 5% might want if it were automatically selected by upstream when color management is employed. The other four options 0% want or need.

Response 2: If the default is doing what 99% of what people want, then don't even try to do better. 99% is *really* good! So just convert to sRGB and SWOP for this class of device and don't even bother bringing it into an ICC workflow at all.


> 
>> If this is a common PPD, we have our work cut out for us on another front which is
>> what options should and and should not appear in PPDs.
> 
> I've no idea why you are reacting this way. The above has been basically
> "industry standard" for 10-15 years.

I've already gone through this. I'm reacting this way because it's brain dead. The sRGB part is easy for upstream to assume and just hand over to the printer as /DeviceRGB PostScript. Cake. The CMYK part is not. The existing PPDs have no mechanism to communicate that CMYK is assumed to be SWOP versus anything else, let alone which specific SWOP it expects. So all the PPDs have to be rewritten to include *cupsICCProfile, with a corresponding profile for the specific CMYK it's expecting; or you have to use a one size fits all for this category of device and always send SWOP, or always send GRACoL or always send ISO 12647 whatever. And it will work OK on some devices and not OK on others.

It's a brain dead workflow. These PPDs are designed in an era and thought process that they are stand alone, and you need 4-foot long levers to control the behavior of the printer. It's not considered at all part of an open system of color management, unless the PPDs are rewritten, and made to communicate important info upstream so that they can be given *even what they claim to want* let alone if someone wanted to use custom or manufacturer ICC profiles with them.


Chris Murphy