[Openicc] Gutenprint mission ... Printer profiling workflow

edmund ronald edmundronald at gmail.com
Tue May 15 03:18:23 PDT 2012

On Tue, May 15, 2012 at 11:19 AM, Kai-Uwe Behrmann <ku.b at gmx.de> wrote:
> Am 15.05.12, 10:44 +0200 schrieb edmund ronald:
>> On Tue, May 15, 2012 at 10:30 AM, Jan-Peter Homann <

>>> Typical tasks for endusers are:
>>> 1) decide, where the printer profile should be used (application,
>>> CUPS/Filter, Driver)
>>> 2) Configure the chain, to avoid double or triple color transformations
>>> 3) create or choose a printing queue / driver setting which relates to
>>> the
>>> printer profile
>>>    3a. Install a standard printer profile for this queue / setting (This
>>> could be also a printer profile which have embedded driver settings)
>>>    3b. Optionally print a testchart  for profiling
>>> From my experience of making printer profiles since 15 years, it makes a
>>> lot of sense, that the tasks of:
>>> - choosing the driver setting (optional with calibration / setup of inkl
>>> limits, ...)
>>> - printing the testchart
>>> - measuring the testchart and calculating the printer profile
>>> - connecting the printer profile and the driver settings
>>> are done in very controlled environment. If possible I would prefer a
>>> solution which by passes CUPS and any filters and sends the testchart for
>>> profiling as bitmap data direct to the printer driver (e.g. Gutenprint).
> That would be possible with PhotoPrint and the Gutenprint plugins for Gimp
> and CinePaint, as they produce native PDL, which to its advantage can not be
> altered by the current printing stack.
 I should repeat that I agree with all of Jan-Peter's requests for
target printing *functionality*,
 Jan-Peter raises the important point of diagnostics, which in fact
would aid developers as much as color consultants and end users
 Now, regarding printing targets, yes it is nice for US DEVELOPERS to
have a direct path to the backend and NO WE NEVER WANT THE GRAPHICS
 Let me be clearer, I'm all for putting the direct-print option there.
For me. For you, For anyone who wants to play with his system. But not
for Jan-Peter to make profiles with . Because what Jan-Peter makes are
profiles that serves for printing user data in the end, and so those
targets should go through the same path as the user data, to avoid
mistakes getting embedded in the code. Targets shoudl be shoved
through the whole CUPS fitler chain, with the "CM-off" flag.
 Because having two print paths is a breeding place for bugs.


 Yes, it would be possible, and

More information about the openicc mailing list