[Openicc] Print-colormanagement, application->CUPS->gutenprint

Hal V Engel hvengel at astound.net
Tue Apr 19 07:37:01 EST 2005


On Monday 18 April 2005 12:06 pm, Michael Sweet wrote:
> Hal V Engel wrote:
> > ...
snip


>
> 3. cupsICCProfile/cupsProfile; these keywords specify a mapping
>     from the PCS to the device/destination colorspace.  In the
>     case of cupsICCProfile, the PCS is typically CIE Lab, while
>     cupsProfile uses CMYK as the PCS.
>
>     cupsProfile has been supported since CUPS 1.0.
>
>     cupsICCProfile is supported in CUPS 1.1.x on MacOS X 10.3 and
>     higher and will be supported later this year in CUPS 1.2 and
>     ESP Ghostscript 8.15.x (x>1) using (surprise surprise) LCMS.
>

Ok this was part of the confusion since this is not yet implemented on any 
open source systems and I don't own a Mac.

> > ...
> > other than paper size settings) requires a different profile to be
> > totally correct.  In addition, each printer of the same model
> > requires different profiles since these will behave differently
> > because of manufacturing variations.
>
> Keep in mind that MOST people will never create their own ICC
> profiles and are 100% OK with using profiles created by the
> developer, so our focus in CUPS is to support simple profile
> selection with support for custom profiles if the user wants to
> create and use them.
>

This is exactly the point that I was trying to get across.  This is not about 
users that don't have exacting color output requirements.  I am sure that 
most of those users are perfectly happy with how this works now.  We are 
talking about the needs of those users that have very exacting color 
management requirements.  Photographers, artists and graphics professionals 
not Joe user who is printing an Open Office document.  These are two totally 
different sets of users with totally different requirements.  

What needs to happen is to somehow allow those that have exacting color 
management requirements to do what they need to do in straight forward ways 
without making things more complicated for everyone else.  In fact I believe 
that if this is correctly designed that it should be possible for 
administrators to set up exacting color management that can be used 
transparently by casual users with out their knowledge .   

For example,  I have tried a number of times to show my wife how to get 
correctly printed photos.  But with my current manual work flow this is 
simply beyond anything that she wants to deal with.  I must add that this is 
beyond what all but the most determined users are willing to deal with.   
After all it is much easier to just ask me to print the photo even if that 
means she has to wait a while to get it.  

On the other hand if this were well designed I could setup a logical printer 
that was fully color managed to very exacting specs.  Then all I would have 
to tell her is "load this kind of paper and use this printer".  Since in this 
ideal world the logical printer would have all of the correct driver settings 
and would also have the right custom printer profile and rendering intent 
setup and locked down she would get exactly the same results that I get 
without having to know anything about color management or complicated work 
flows.  Our goal should be to make this possible or even simple to do once 
there is a custom printer profile in hand.  

>  > ...
> >
> > I need a good way to manage these in conjunction with the related
> > printer settings that go with each profile.   This needs to be simple
> > to do for those who are responsible for creating and installing
> > profiles but transparent to regular users.
> > ...
>
> Our current design is to support user-installed profiles in
> addition to the usual profile auto-selection based on the current
> job options.  How the user installs the profiles is beyond the
> scope of CUPS, however the design makes it as simple as an admin
> user creating a symlink or a nice GUI doing this for the user.

A symlink from where and to what?  How do I specify that for printer W 
(meaning a specific physical printer), at resolution X, on paper Y, with 
dithering algorithm Z, ink set A.... that this is the correct profile and 
rendering intent to use with a symlink?  I must have that level of control or 
this does not do the job.  This is a high level requirement and I don't care 
how it is implemented but I don't see how this is possible with a synlink.  
Perhaps you could spell this out for me so that I understand how this would 
work.


Hal



More information about the openicc mailing list