[Openicc] Printing Plans... Testcharts

[Kai-Uwe Behrmann]

Am 07.03.11, 20:24 +1100 schrieb Graeme Gill:
> Jan-Peter Homann wrote:
>> I don´t think, that such printing, calibration and profiling tasks
>> should be handled through the complete CUPS chain.
>
> Creating separate workflows can make things unreliable if
> accidentaly different treatment creeps in. Using a very similar
> process to that used for calibration & profiling, it should be
> possible to verify that the calibration or profiling is
> having the intended effect in the print workflow.

With the later I agree.

>> Using a utility directly interacting with the driver like e.g.
>> Gutenprint will be much more transparent and failure proof.
>
> Expecting the profiling package to directly interact with
> the printing environment would multiply the work needed
> in creating a calibration & profiling application considerably.
> There should always be a method of performing this sort of task
> in independent steps, both to allow a wide range of mix and match,
> and to be able to diagnose what's going on.

The question is how to get the PPD calibration part out of the way.
I found Jan-Peter's listing of what is what quite helpfule to give them 
names. Maybe some further to be defined meta tagging can help getting this 
sorted.
Questions come like:
* what is the basic calibration stage?
* how is raw printing, before ink limiting, to be labeld and communicated?
...

> Direct interaction with the printing environment should be possible
> (for a smoother user experience), but not essential.

I am a huge fan of Gutenprint. But from a architecture and usability point 
of view its better to need not too much specialities. Calibration and 
profiling are very common tasks. Having them integrated, in PPD, would be 
a big plus for Linux environments.


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