[Openicc] Printing Plans GhostScript / sRGB / ICC

Kai-Uwe Behrmann ku.b at gmx.de
Sun Mar 6 00:21:01 PST 2011


Am 06.03.11, 18:54 +1100 schrieb Graeme Gill:
> Hal V. Engel wrote:
>> The only time pass through or not is ambiguous is when there is no
>> OutputIntent and the objects are tagged as DeviceXXX and there is only one
>> DeviceXXX type used and it matches the printer color mode.  A CM aware app
>> wanting it's already CMed spool file to pass through should set the 
>> profiles of
>> the embedded objects == the OutputIntent and it will get pass through since
>> this is completely unambiguous.  The main thing is to make sure that
>> pdftoraster honors OutputIntent.
>
> Relying on matching profiles is pretty dodgy, and provides no
> mechanism for necessary control over calibration state.

The DeviceXXX == OutputIntent mechanism is a pass through. A rasteriser 
should IMO special case that. The rasteriser is best informed about 
DeviceXXX == OutputIntent, as it is defined in one single PDF file.
A CMS could not disturb that other that breaking the PDF spec.

> For doing calibration runs, both profile based modifications

DeviceXXX == OutputIntent should be sufficient for that to happen.

> and calibration should be disabled. Then there is the distinction

That will need a new agreement as many print drivers do calibration 
completly different. Basical this is about PPD options I guess. But simply 
disabling or default all ColorKeyWords listed PPD options might not be 
enough to disable the calibration.

Gutenprint has a raw printing mode. As well Edmund plans to put the 
calibration as a Gutenprint specific preset inside the PPD. Perhaps Edmund 
and Robert can comment.

What is not clear to me is, how does the measurement of a uncalibrated 
driven test chart can be converted into calibration data? Would that be a 
device link profile, which contains just the channel curves for 
linearisation on top of more basic settings like density?

> between native device channels (light black, medium black, black)

thats DeviceN

> and composite device channels (light/medium/full blended into
> a single black channel). If you don't want to have to go

thats DeviceCMYK

> around again at some later stage (or deal with lots of stuff
> that doesn't work properly), then now is the time to anticipate
> these requirements.

Agreed, different utilities should play well together in order to make 
calibration and profiling easy. That will as well help to get good print 
profiles for sharing and distribution.

kind regards
Kai-Uwe Behrmann
-- 
developing for colour management 
www.behrmann.name + www.oyranos.org



More information about the openicc mailing list