[Openicc] Printing Plans GhostScript / sRGB / ICC

[Chris Murphy]

On Mar 7, 2011, at 6:35 PM, Graeme Gill wrote:

> Chris Murphy wrote:
> 
>> 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.
> 
> Why would the none setting be "automatically selected" ???

Upstream the user has asked for prematching with an ICC profile in an application. Or they have asked for "mid-stream" matching by Ghostscript by choosing an ICC profile in the CPD.

Why should the user also have to know they need to disable the equivalent of "screw everything up" mode?


> 
>> 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.
> 
> It (probably) is an ICC workflow. ICC profiles are (probably) used to set
> the colorspaces selected by the PPD settings.

I disagree, those are almost invariable CSA's in the PPD telling the PostScript generation libraries to insert them into the created stream, or they are metadata to tell the printer to assume certain CSA's that are build into the printer. There's no mechanism for PostScript printers to use ICC profiles directly.



> Nothing about the
> PPD settings (should) affect how tagged sources are treated, this
> is all about how to deal with DeviceXXX.

Early on in this thread I asked if anyone had a good reason why /DeviceRGB would be anything other than None or sRGB. No one responded. I made the arguement that there's simply no use case for Adobe RGB, ColorMatch RGB, or any other RGB, except by admitting an upstream process somewhere is screwed up and tags are being dropped.



> 
>>> 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.
> 
> Typically this type of printer isn't aimed at the graphics art level,
> so a set of CMYK presets is fine. The next level is being able to
> set what the defaults correspond to in the printer/RIP. That makes
> color a solvable problem for the graphics arts people. Downloading it
> in the PPD ? well anything is possible, but you should probably tag
> the source material in the PDL instead.
> 
>> 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.
> 
> It's a reality due to the number of "color dumb" applications out there. None of
> that interferes with the ability of "color smart" applications to communicate
> what they want.

As I said, if it's *really* perceived to be working for 99% as you say, then there is no problem to solve (other than it's ugly and ridiculous and confusing). We should not change a single thing, and instead focus on other problems.


Chris Murphy