[Openicc] Printing Plans GhostScript / sRGB / ICC

[Graeme Gill]

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" ???
It is there for 1) profiling 2) application managed color

> 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. Nothing about the
PPD settings (should) affect how tagged sources are treated, this
is all about how to deal with DeviceXXX.

>> 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.

Graeme Gill.