[Openicc] CUPS Color Management under Linux... (what is to do ?)

[Hal V. Engel]

On Wednesday, February 09, 2011 10:26:39 AM Chris Murphy wrote:
> On Feb 9, 2011, at 9:46 AM, Jan-Peter Homann wrote:
> > PDFtoRaster
> > It is important to define, how the current valid cupsICC profile is
> > merged into the print workflow: - placed as PDF Output Intent in the
> > print spool PDF (this needs a e.g. specialized CUPS filter to do this),
> > before it is send to PDFtoRaster. In this case PDFtoRaster don`t needs
> > any configuration for the cupsICC profile.
> 
> I think the most appropriate place is right at PDF print spool generation
> time. Obviously the ideal is for every PDF print spool file to perfectly
> state its case in all respects, including color intent and how it is to be
> converted for printing. But I'm not familiar enough with what actually
> produces the PDF print spool file to know how reliably it will tag objects
> correctly, including the setting of (at least) a default OutputIntent.
> 
> If the generation of the PDF print spool file is centralized, and can be
> made consistent, great. Then pdftoraster, pdftops, pdftotiff, pdftoOTHER
> all just need to share some code to properly interpret these PDFs with the
> help of Ghostscript, to produce consistent results as raster, postscript,
> tiff, and OTHER file formats that represent the intent of the PDF. Also,
> if this is always reliable, then we can enable our explicit color
> management off switch for calibration and profiling devices very literally
> as well (i.e. no ICCBased objects, no OutputIntent, and that's the off
> switch). So is there some single library or process that all applications
> can use to produce a PDF print spool file? I suspect not, but have to ask.
> 
> If the PDF print spool file can't be guaranteed to be PDF/X (I think we are
> talking about X-4, or X-4p, that's something else to be discussed,
> including Ghostscript 9 capabilities), then we need a fallback position to
> "fix" these PDF print spool files. Fixing means setting assumed source
> color spaces for objects, and also a destination profile for the printer
> (either user specified or a default in the PPD).
> 
> Option A:  pdftoraster and pdftoXXXX filters all need to be updated to
> "fix" the incoming PDF by assuming source spaces in lieu of /DeviceRGB and
> /DeviceCMYK, and a destination space based on *cupsICCProfile in the PPD.
> If the incoming PDF is PDF/X, then it's not "fixed", it's simply
> interpreted. This would affect all PDF print spool files.
> 
> Option B: Move this "fixing" of the pdf to a prefilter, called pdftopdf,
> whose job would basically be to parse for PDF/X print spool files. If they
> are not already PDF/X print spool files, it would turn them into such
> files, with proper ICCBased sources and an OutputIntent so downstream
> filters can properly and consistently color manage them. Only PPDs that
> use *cupsPreFilter and point to this pdftopdf filter would use it. So that
> means PPDs need to be updated (not a big deal since they need to be
> updated to use *cupsICCprofile to have a meaningful default OutputIntent
> anyway). Any PPD not updated this way, would not use the pdftopdf filter,
> and it's PDF might not be PDF/X once it gets to pdftoraster or pdftoXXXX.

Option C: Have the CPD handle it.  We could have an app settable switch in the 
CPD that could be turned on if the app thinks it is smart enough to create 
PDFs that contain propper CM information.  This switch would be off by default 
so that CM dumb apps would not have to be aware of it to function "correctly".   
That is apps that set the switch would be signalling that they are aware of CM 
and that the CDP should trust them to do the right thing. So it would work 
like this:

1.  If an app turns this switch on and then sends a PDF with only DeviceXXX 
objects and with no OutputIntent then this is an app that is explicity 
requesting that the output go unaltered to the printer.   There is absolutely 
no ambiguity.

2. If an app sets the switch and tags the objects with ICC profiles and/or 
other unambiguos color spaces (IE. CIELab or CalRGB for example) but does not 
set the OutputIntent then we know it is requesting the default system 
OutputIntent (IE. the profiles coded in the PPD or whatever comes from the 
system - Oyranos or colord provided profiles for example).   In this mode and 
the one below I think it is OK for the print job to fail if ANY object in the 
PDF is not tagged with some CIE color space, an ICC profile or other unambigous 
color space.   In fact it should be manditory since the app clearly made a 
mistake when it created the PDF spool file.

3. Like #2 except the app sets an OutputIntent and it is over riding the 
system default profile.  The profile setup in OutputIntent will always be used.  

4. If the app does not set this switch then we know it is CM dumb and any 
untagged RGB objects are assumed to be sRGB and will be tagged by the CPD that 
way before the PDF is sent to CUPS.   Most existing apps will be of this type.  
This is the "it just works" case where the app sends the CPD a PDF that may 
not be well formed from a CM point of view and it expects the printing workflow 
to do the best it can with it even if the result is not perfect.  I am not 
sure what to do if such a file has CMY(K) objects.  Perhaps tag these with a 
SWAP profile or something similar?  On the other hand I don't expect too may CM 
dumb apps to create anything other than RGB output.  The CPD is already linked 
to poppler and poppler can be used to modify the PDF and write a new version 
with generic ICC profile tags for untagged objects before handing it off to 
CUPS.

I know that much of the CPD effort on the GTK apps side wil be to setup a frame 
work for creating PDF spool files since this is not supported out of the box by 
GTK.  This is not needed on the Qt side since Qt has this already built in and 
has had this functionality for some time now.  For the non-developers here Qt 
and GTK are to two most used "widget sets" on X11 systems.  These are shared 
libraries that provide a high level frame work for apps to do things like 
create app windows and dialogs and other user functionality like printing.  

On the Qt side I don't know specfically what PDF specs are supported.   I just 
spent some time looking but this information is not part of the Qt docs.   I 
will ask Qt support for this info.  But at least on the GTK side we can 
influence this and make sure that it is always PDF/X-whatever and have this out 
of the box.   On the Qt side we will have to see what it is currently doing 
and if it is not doing PDF/X of some sort we will need to figure out what needs 
to be done to move forward.

The advantages of having the CPD handle this are:

1. It is all in one place.

2. We can provide hooks for apps that will help CM smart apps to better 
integrate into the CM printing work flow.

3. Any full function CM printing work flow will need to have at least some 
functionality in the printing UI/front end to support CM.   We might as well 
start figuring out what belongs there now rather than later since this 
functionality will be fairly cheap to add at this point.

4. This will allow for integration of the printing UI with Oyranos/colord type 
utilities which I think will be required in the long run. 

Disadvanges are:

1. The CPD needs a significant amount of work and may not be ready for some 
time.  Till care to comment on this?


> 
> Option B provides abstraction of what we're doing to these PDFs, it doesn't
> force so much "fixing" into the pdftoXXXX filters. It's probably easier to
> troubleshoot things. It encourages a PDF/X workflow rather than burying it
> into pdftoraster and pdftoXXXX, where inside of those you do not actually
> create PDF/X and then interpret it, you'd just do substitutions. For
> troubleshooting, we can always change PPDs to redirect files to be written
> to disk at each CUPS stage and inspect the file at that stage. So option B
> makes the primary pdftoraster and pdftoXXXX filters less of a black box.
> But then it also is more complicated in that it has to thoroughly
> understand possibly all sorts of incoming PDF print spool files, and be
> able to write them out as PDF/X to whatever conformance level we are
> agreeing on. And option B provides a total pass through very easy for any
> PPD not asking for pdftopdf. It does very much make color management
> opt-in (optional) in the print pipeline, rather than opt-out. The former
> is more consistent but requires effort to get out of, and the latter is
> less consistent and the default.
> 
> A separate topic for openicc is "pdf print spool file, what pdf format?"
> 
> 
> 
> Chris Murphy
> _______________________________________________
> 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/20110209/ebf909b2/attachment-0001.htm>