This conversation is quickly pointing out the need for a metacontrol such that the users can direct behaviour using user friendly terms such as "I want to proof" and then having a control structure under the hood to make the choices of profiles accordingly.  Looking ahead, the new metadataTag in ICC can be used to label profiles internally so they can be selected properly by such a control structure. If we are thinking about changing PPD -- then perhaps this concept can be considered. Best regards, Ann McCarthy Imaging Systems R&D Lexmark Imaging Solutions Division Lexmark International, Inc. <table width=100%> <tr valign=top> <td width=40%>Chris Murphy <lists@colorremedies.com> Sent by: openicc-bounces+almccart=lexmark.com@lists.freedesktop.org 05/17/2010 12:45 PM <td width=59%> <table width=100%> <tr valign=top> <td> <div align=right>To</div> <td>openicc Liste <openicc@lists.freedesktop.org> <tr valign=top> <td> <div align=right>cc</div> <td> <tr valign=top> <td> <div align=right>Subject</div> <td>Re: [Openicc] Google Summer of Code 2009: Oyranos CUPS backend</table> <table> <tr valign=top> <td> <td></table> </table> <tt>For the Epson Stylus Pro 3880, there are 12 manufacturer supplied ICC profiles totally 8.5MB in size. Each profile is 760K in size, roughly. Which is 1/3 to 1/4 the size of a good production quality profile. Now, this is probably OK quality for casual soft proofing. If you're looking to get better results (for printing as well) then better profiles are needed. As far as I'm aware, SEC doesn't supply them, however Epson America does make better profiles available via separate download. So what if user@printerhost has downloaded or created superior profiles, and uses those for soft proofing and printing. But then user@remote is subject only to using PPD based profiles? (Or manufacturer supplied profiles?) It would be nice if there were a way for user@remote to have the option to use the better quality profiles, without having to download inferior ones first. cupsICCProfile is URI based isn't it? While it can be argued the settings of user1 should not affect the settings user2 is subject to, I think a case can be made that user1@printerhost is in a vastly better position to know what media is presently in the printer and thus what ICC profiles apply to the various printing modes, if they're going to be used at all. So if they've overridden them, it's probably a good idea for the option to present the remote user with alternate profiles. It might even be a good idea to suggest them as the default. Another way to do this entirely would be three subset profiles that are only used for soft proofing, and are non-binding on the print job. Those categories would be: plain paper, glossy, and matte medias. While there clearly are differences between different matte media I think a single profile representing most matte media on the printer can set expectations at this level appropriately. Same for gloss. Same for plain paper. Once the job arrives at the printerhost machine, then the correct profile based on actual media loaded (and perhaps a custom profile as specified by that printer's owner) is used for actual matching. Chris On May 17, 2010, at 10:06 AM, Kai-Uwe Behrmann wrote: > A spooler is not required to pass a ICC profile from a remote location to a local host. This is still very much needed to support local proofing. > > Given that CUPS' cupsICCProfile is just a name without garantee to see the profile in applications, embedding seems the only option? Or how could it be made a requirement to obtain the profile? > > > kind regards > Kai-Uwe Behrmann > -- > developing for colour management www.behrmann.name + www.oyranos.org > > > Am 17.05.10, 09:39 -0600 schrieb Max Derhak: >> As Chris Murphy pointed out, I would be wary of assuming a one to one >> relationship between a printer and a single profile.  Potentially each >> media, output resolution, and halftoning strategy needs to have a >> different profile.  Ideally you want to have something that allows all >> the printing condition settings to select the profile. >> >> My understanding is that this doesn't lend itself to using PPD's easily. >> >> Max Derhak >> Senior Software Architect >> max.derhak@onyxgfx.com >> >> >> -----Original Message----- >> From: openicc-bounces+max.derhak=onyxgfx.com@lists.freedesktop.org >> [mailto:openicc-bounces+max.derhak=onyxgfx.com@lists.freedesktop.org] On >> Behalf Of Kai-Uwe Behrmann >> Sent: Monday, May 17, 2010 9:22 AM >> To: Leonard Rosenthol >> Cc: Dov Isaacs; OpenICC Liste >> Subject: Re: [Openicc] Google Summer of Code 2009: Oyranos CUPS backend >> >> Am 17.05.10, 11:09 -0400 schrieb Leonard Rosenthol: >>> On Mon, May 17, 2010 at 10:51 AM, Kai-Uwe Behrmann <ku.b@gmx.de> >> wrote: >>> >>>> What you propose is particially related to the "cupsICCProfile" PPD >>>> keyword. By this keyword the ICC profile is only named and not >> embedded in >>>> the PPD as you suggest. >>> >>> >>> In addition, cupsICCProfile isn't supported by desktop applications >> (such as >>> Adobe Acrobat/Reader) on any OS platform and certainly not in any >> situation >>> on Windows.   Is it widely enough used to even consider trying to >> support >>> it?  Certainly none of the major vendors are including this in >> profiles >>> supplied with printers - does it only appear in a customized CUPS >> driver >>> installation? >> >> We have practical no support for cupsICCProfile on Linux. It supports >> too >> few use cases. Linux is much networked. A PPD embedded ICC profile would >> >> be prefered. >> >> >> kind regards >> Kai-Uwe Behrmann >> -- >> developing for colour management >> www.behrmann.name + www.oyranos.org >> > _______________________________________________ > openicc mailing list > openicc@lists.freedesktop.org > </tt><a href=http://lists.freedesktop.org/mailman/listinfo/openicc><tt>http://lists.freedesktop.org/mailman/listinfo/openicc _______________________________________________ openicc mailing list openicc@lists.freedesktop.org </tt><a href=http://lists.freedesktop.org/mailman/listinfo/openicc><tt>http://lists.freedesktop.org/mailman/listinfo/openicc </tt></a></a>