[Openicc] Printing Plans GhostScript / sRGB / ICC

[Graeme Gill]

Chris Murphy wrote:
> Upstream the user has asked for prematching with an ICC profile in an application.

That's what it's there for.

> Or
> they have asked for "mid-stream" matching by Ghostscript by choosing an ICC profile in
> the CPD.

There is no Ghostscript in this situation - the PPD is part of the front end
to the RIP.

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

I've no idea what you mean. You seem to be assuming that someone is proposing all
this and that it somehow can't work. The opposite is true - it's well tried and
tested in the field, and is a workable approach technically and from a user
point of view.

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

Incorrect. Many RIPs have mechanisms that allow other color transformations
to be substituted for CSAs. I implemented this in both JAWS and Adobe CPSI.
And I helped implement a very similar ICC based DeviceXXX mechanism in
CPSI (for a customer) that used CSAs internally - I wrote the code to
convert the input profiles to CSAs and the output profiles to a CRD.
The RIP UI allows profile loading and selection.

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

It's a practical mechanism for dealing with "color dumb" applications
that only know about DeviceXXX spaces. The user keeps track of the of
the colorspace tagging, and the PPD setting is a way of them passing the "tag"
along. The undesirability of this approach is what prompts the use of
real tags. Unfortunately there are still a lot of "color dumb" applications out there
though, and it often becomes a fallback mechanism when some clever piece of code
isn't working, or application writers assumption isn't true.

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

Yes, I agree. It's a practical way of dealing with DeviceXXX and "color dumb"
applications, and it would save a lot of time and effort in re-learning all
this, to pick the best bits and move on.

Graeme Gill.