[Openicc] Gutenprint mission ... Printer profiling workflow

[Chris Murphy]

On May 15, 2012, at 7:23 AM, Graeme Gill wrote:

> Kai-Uwe Behrmann wrote:
>> Does ArgyllCMS have a print client for Gutenprint?
> 
> No, nor is it likely gain one in the near future.
> Argyll currently creates platform independent charts
> ie. PS, EPS & TIFF files. Conceavably it could create PDF files.
> 
> If there was a standard way of tagging these files as to how
> they should be treated, then they could be submitted in any
> number of ways with some confidence that they will work as intended.
> Currently, it's up to the user to figure out how to turn the
> appropriate color processing off.
> 
> [It would be nice to get Microsoft, Apple, Adobe, etc. etc. to
> agree on this though :-)]

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.

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

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

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.


Chris Murphy