[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