[Openicc] Gutenprint mission ... Printer profiling workflow
ku.b at gmx.de
Wed May 16 01:14:38 PDT 2012
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.
More information about the openicc