<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd"> <html><head><meta name="qrichtext" content="1" /><style type="text/css"> p, li { white-space: pre-wrap; } </style></head><body style=" font-family:'DejaVu Sans'; font-size:12pt; font-weight:400; font-style:normal;"> 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</body></html>