[Openicc] Google Summer of Code 2009: Oyranos CUPS backend

Hal V. Engel hvengel at astound.net
Mon May 17 10:24:48 PDT 2010 

On Monday 17 May 2010 09:45:24 am Chris Murphy wrote:
> 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 at printerhost has downloaded or created superior profiles,
>  and uses those for soft proofing and printing. But then user at remote is
>  subject only to using PPD based profiles? (Or manufacturer supplied
>  profiles?) It would be nice if there were a way for user at 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 at 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

For the most part I agree with Chris although I am not sure I agree about 
using three generic proofing profiles.  The more likely case is that "user1" is 
the print server admin.  If that admin or his/her organization is concerned 
about color management then it should be possible for them to setup the server 
to use the correct custom profiles for each printer/media/setting combination 
and to even possibly restrict users to only a subset of the available settings 
so that the profiles installed on each server are an exact match for the 
settings that the user selects. 

In any case one profile per printer is not sufficient since the profile is likely 
different for each media type, resolution and other settings combinations.   
Unless the profile settings has been hand configured in the PPD by the server 
admin this is the printer (or printer driver) vendors problem to deal with.   
I know that many printer vendors make numerous profiles available to users.  
Chris's Epson example is a good one and I know for my printer that this 
downloadable profile package has over a dozen profiles.   In addition these 
profile packs from Epson only cover a small subset of the available media and 
settings combinations for these printers which indicates that in a print 
server situation that the local admins should be able to restrict printer 
settings to those that are valid for the installed profiles such as one of 
these profile packs.  

It is clear that the printer vendors (at least some of them) are aware of the 
need for more than a single profile for each printer.  In addition, it is 
common for third party media vendors to supply semi-custom profiles for various 
media/printer combinations.  So there is a need to accommodate these vendors 
profiles as well as custom user created profiles.  Clearly this is not a simple 
problem and it is not amenable to simple solutions. 

For those users using CUPS where are user defined or third party vendor profiles 
supposed to be configured if not in the PPD?  CUPS has no other place to do 
this and CUPS will only apply profiles that are defined in the PPD or installed 
in a specific location on the CU PS server.  In addition, there is no way for 
users to get lists of or copies of profiles installed on the CUPS server other 
than those configured in the PPD.  So proofing is only possible with profiles 
that are configured in the PPD at least for non-local servers.

As a result either we use the PPD to configure custom profiles which currently 
has many issues or we come up with another system to handle profile management 
for printers and integrate this with CUPS (IE. by pass the PPD totally for 
color management).  I actually favor the second approach since the PPD system 
is so inflexible and has so many issues with regard to color management.

I also have concerns about directly embedding profiles into the PPD.  PPD files 
are currently fairly small.  The ones on my system are between 46K (guten 
print HP500) and 600K (guten print Epson R2400) in size.  Once we start 
embedding profiles into these their size will explode.   After all in some 
cases the vendors have 5, 10 or more profiles for each printer model.  Looking 
a Chris's example embedding these profiles would increase the size of the PPD 
by over an order of magnitude.  Since many installations use remote print 
servers this means that this will result in a significant increase in network 
traffic since apps using the printer will need to get the PPD in order to 
function correctly.   Even those apps that do not care about color management 
will cause this traffic increase when the user opens the print dialog.

Hal

> 
> 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
> >
> >> 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 at onyxgfx.com
> >>
> >>
> >> -----Original Message-----
> >> From: openicc-bounces+max.derhak=onyxgfx.com at lists.freedesktop.org
> >> [mailto:openicc-bounces+max.derhak=onyxgfx.com at 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 at 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
> >
> > _______________________________________________
> > openicc mailing list
> > openicc at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/openicc
> 
> _______________________________________________
> openicc mailing list
> openicc at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/openicc
>

More information about the openicc mailing list