[Openicc] What is exactly needed: Embedded Profile in CUPS raster !!
Hal V. Engel
hvengel at gmail.com
Thu Jun 2 14:58:49 PDT 2011
On Thursday, June 02, 2011 01:59:42 PM Michael Sweet wrote:
> On Jun 2, 2011, at 1:07 AM, Alastair M. Robinson wrote:
> > Hi,
> Automatic profile selection works just fine for the settings ordinary users
> are likely to tweak, primarily color mode, media type, and print
> quality/resolution (thus the defaults used for cupsICCProfile).
For nave users having a set of vendor supplied profiles configured in the PPD
that are automatically selected will work. But this runs into a wall when
someone with CM expertise is trying to setup a custom CM solution that is
usable by other users. PPD files are intended for vendor supplied configuration
and are not well suited for supplying customized/local functionality because
of their static nature and the fact that the customizations are very easy to
lose during system upgrades.
> It makes
> sense to embed the configuration/calibration settings used when printing a
> target and generating a profile. It makes less sense that a user might
> choose a profile they've done previously and then change the driver
> settings that it depends on.
The real issue is making sure that the user, who in many cases does not know
anything about CM, gets the correct driver settings by default when a custom
profile preset is selected. If users choose to change settings after they have
selected a custom profile preset and that gives them bad results that is on the
user and I am not sure there is anything we can do about it.
> > Also there's a one-to-many relationship between printer settings and
> > profiles which can't be taken into account by a system that
> > automatically selects a profile from a bundle of settings. (The system
> > can't know which particular paper I have loaded when several different
> > brands of glossy paper need the same print settings but different
> > profiles.)
> Um, perhaps you missed this, but if you have two different kinds of
> "glossy" media you give then two different names. Aside from the custom
> option support in CUPS, a profiling application that updates the PPD file
> to list additional/different profiles could also inject alternate media
> types matching what was actually used. With two different names you never
> have a one-to-many relationship but you may have a many-to-one
> relationship since a single profile may work for multiple combinations of
Again this requires making custom modifications to the PPD file which is
something I think should be avoided.
> > Using the Choose Profile -> Implies Printer Settings paradigm does solve
> > a number of issues and I think it's pretty compelling.
> I think having a named preset that selects both the driver settings and
> profile is a compelling solution. I don't see "pick an ICC profile" as
> particularly useful or easy-to-use ("what's an ICC profile?")
I agree with this and I think this is the correct approach. It is possible
for the CPD to have custom (IE. not from the PPD) presets and in another
thread I wrote that it should be possible to use these to bundle a profile and
it's setting and give this preset bundle a meaningful name for users to select
from the presets drop down list.
This is sort of analogous Jan-Peter's suggestion to use different queues to do
multiple profiles per printer but this is a more elegant as it more closely
matches how users would view how the system works.
Getting back to Alastair's example of using two photo papers with custom
profiles in the same printer. The use of custom presets makes sense in this
context since the presets could be given meaningful names (IE. XYZ Photo Paper
and ABC Photo Paper) and it would be apparent to anyone using the printer what
preset to select for each paper type even if both papers were mapped to the
same underlaying PPD media type.
I don't know if the current CPD supports the creation of server side custom
presets but it does support creating these for users. The user presets
should allow for user specific custom CM work flows but I think that we do need
the ability to create server side customized presets so that CM experts can
create these for use by CM nave users.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openicc