[Openicc] Gutenprint mission ... Printer profiling workflow

[Kai-Uwe Behrmann]

Am 15.05.12, 13:42 -0600 schrieb Chris Murphy:
> I vaguely recall a discussion, maybe a year ago, about this. PDF had an 
> unambiguous way to describe a PDF whose contents should not be 
> transformed. But the /device spaces have been hijacked by virtue of 
> assumed and default source profiles. So it's arguably no longer 
> ambiguous when "no transforms" is specified.

PDF/X-3 is the still worked on answere for this question.

> It also came up before the ICC, to come up with an embeddable "no 
> transform" profile to describe an object that should be immune from 
> transforms. That ICC profile class was never produced. And probably just 
> as well because usually apps don't insert the entire binary data of a 
> TIFF or JPEG into the print stream, just that portion that can be 
> printed. The profile metadata is stripped by all unaware apps, so for 
> those file types the efficacy is effectively zero (or worse than zero 
> since it sets the wrong expectation).

IMO the "no transform" profiles would play in a similiar league like the 
implicite input==output space non conversion, but without a specific 
context, which is even more irritating.

> It's even possible a PDF reader will extract objects, causing a whole 
> new PDF spool to be produced, rather than insert the existing PDF into 
> the print stream. So I'm not sure it can be made reliable even for PDF 
> (or XPS).

We have to assume to print from colour management aware applications in 
order to calibrate and profile. But that should not surprise. If 
extraction does not work for ICC tags, then that is a bug in the app, and 
either it is fixed or will not be recommendable.

> To get color management enabled for dumb apps, we have to second guess 
> their claimed usage of device space. Upon second guessing their claimed 
> usage of device space, we now need an alternative way to specify when 
> device space is really wanted. I don't see that we're going to get away 
> with this by tagging the target files themselves, it seems inevitable 
> we'll need an application or advance print dialog option that attaches 
> job ticket metadata to get the behaviors we want/need.

The profiling of dump apps is a special case, which Edmund wanted to be 
able to do. This is nowhere a normal use case, where naive users hit the 
nail immediately on the head. It is a try and guess path for those who 
are ready to spent considerable time in highly customised and non standard 
workflows. That was clearly stated.

kind regards
Kai-Uwe