[Openicc] CUPS Color Management under Linux gets into distros

[Hal V. Engel]

On Tuesday, February 08, 2011 09:43:08 AM Till Kamppeter wrote:
> On 02/08/2011 06:04 PM, Kai-Uwe Behrmann wrote:
> > Great news. A ICC enabled pdftoraster filter is a huge step forward for
> > colour managed printing. Many thanks for your work on that.
> 
> Also thanks to Otani-san who wrote this filter and also many other PDF
> filters.
> 
> >> Color management experts from OpenICC, WDYT about this color
> >> management effort? Is this already a step forward? Is it at least the
> >> correct effort for
> > 
> > Yes, such a pdftoraster filter is a pre condition for any main stream
> > colour management on Linux.
> > 
> >> consumer-level printing? What needs to be added to support pro and
> >> prosumer printing?
> > 
> > I think consumer lever printing with canned profiles might be already
> > served to some degree by your announced changes and CUPS capabilities.
> > Vendors can bundle their drivers, PPDs and ICC profiles to deliver a out
> > of the box improvement. The same for administrators to setup colour
> > managed queues.
> > 
> > 
> > The recent weeks we discussed here on OpenICC in length about user side
> > colour managed printing. As PDF, CUPS, Poppler/Ghostscript and CPD are
> > rather complex, we had many thoughts about it. The question was more or
> > less, how can users opt-out of colour management
> > for calibration. And how to assign own profiles to a print job to
> > override the PPD configured profiles. As well passing rendering intent
> > and black point compensation options is yet unclear to us.
> 
> Otani-san, if one has a print queue with installed ICC profiles, is
> there an easy way to turn off ICC color management with your
> pdftoraster? This way advanced users could do a calibration to create
> their own ICC profiles. Also can one override the PPD's ICC profiles to
> use user-supplied ones (for example embedded in the pDF job)? What about
> sending rendering intent and black point compensation along with a job?
> Can you, if needed, add options to the pdftoraster and/or the
> possibility to read info/data embedded in the PDF jobs?

It appeaers that at present poppler does not support either rendering intent 
or BPC.  At least I don't find anything on the poppler email list about this 
since May 2009 when it was stated that this was a very complex problem and had 
not been addressed yet.

"As Leonard said INTENT can come from several places, it's not so
simple to handle INTENT correctly. We have to check if current INTENT
is changed and recreate transform if needed.
This is why I didn't support INTENT this time."

I have not been able to locate any additional threads on the email list about implementing 
rendering intent.  I also had a quick look at the code and I didn't find anything that sets the 
rendering intent for CM other than two places where relative colormetric is hard coded in 
the cmsCreateTransform call.  This appears to be unchanged since 2009.  So it appears 
that poppler currently always does relative colormetric intent regardless of what intents 
in coded into the PDF file for it's objects.  I can live with this for initial testing of the 
workflow but it does need to be fixed before this is considered production. 

> 
> > I tried to summarise some of the issues without giving it a proper
> > architectural shape yet. However these notes might help to understand
> > where the discussion stands:
> > https://www.oyranos.org/wiki/index.php?title=Device_Settings#Printing
> 
> For the "wget http://localhost:631/profiles/sRGB.icc" problem, there is
> an STR on
> 
> http://www.cups.org/str.php?L2896
> 
> Please add your comments.
> 
> A possibility to send user-supplied profiles along with a job could be
> embedding the profile in the PDF job. The Common Printing Dialog would
> be the best place to do this. pdftoraster would need a feature to read
> out such profiles and use them instead of the PPD-specified ones.
> 
> You should mention on the Wiki page that Poppler supports ICC color
> management, too.
> 
>     Till
> _______________________________________________
> openicc mailing list
> openicc at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/openicc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/openicc/attachments/20110208/32ae8172/attachment.html>