[Openicc] What is exactly needed: Embedded Profile in CUPS raster !!

[Hal V. Engel]

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,
snip
> 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
> settings.

Again this requires making custom modifications to the PPD file which is 
something I think should be avoided.

snip
> 
> > 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.  

Hal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/openicc/attachments/20110602/64f2f33d/attachment-0001.htm>