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

[Chris Murphy]

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 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