[Openicc] Is CUPS the right place... (CUPS and ColorSync)

[Jan-Peter Homann]

Hello Chris,
Thanks very much for the clarification about CUPS and ColorSync.

But we still should consider, that the described workflow has some 
critical points.
If all parts of the PDF should be converted to the profile of the 
printer setting by embedding this profile as Output Intent into the PDF 
file, it is mandatory, that every PDF-object is a ICCbasedRGB or 
ICCbasedCMYK object.
If a PDF file contains DeviceRGB or DeviceCMYK objects, ColorSync will 
change such PDF objects automatically and without warning to ICCbased 
mainly by embedding e.g. the ColorSync standard profiles in every PDF 
object (images, vector graphics, text...)

Especially in Graphic Arts workflow, which use e.g. PDF/X-1a workflow, 
where all PDF content is e.g. DeviceCMYK, such automatic conversion 
without warning can make a PDF file unusable by just importing it into a 
ColorSync environment and save it again.

Because of this, graphic art users under Mac OSX avoid the Mac OSX 
function "Save as PDF" from the Apple printing dialogue.

The main problem here is the role of the Output Intent

In "classic" Graphic Arts workflows, the Output Intent is the same as 
the document color space.
E.g. SWOP or ISOcoatedv2 is the intended output. If such a PDF file 
should be printed on a inkjet, the user wants to simulate SWOP or 
ISOcoatedv2 on his inkjet.
This is solved by using the output intent as source profile and printer 
setting profile as target profile during printing. (daily business in 
proof printers)

If we use the ColorSync approach of tagging every PDF object only for 
the print pipeline, it may can work quite well. But using the same 
approach also for PDF Export can lead to results, the user don´t wants.

Because of such experiences, I suggest for the first steps with PDF and 
colormanagement a "Flat color approach" where the output Intent 
represents the document color space.

If we can manage such workflows both for printing and PDF-Export, we can 
move to more complex workflow dealing with ICC-profiles both on PDF 
object level and output intent.

Best regards
Jan-Peter






Am 07.02.11 22:00, schrieb Chris Murphy:
>
>
>
>
> Yes, that is the job of *cupsICCProfile. It allows a print dialog to 
> cross reference settings with an ICC profile, which is then returned 
> back to the application (or whatever) writes out the PDF. The profile 
> is then placed in the PDF print spool file as the OutputIntent, if you 
> are using ColorSync Color Matching, or if you're using application 
> color matching (but not if you're using the 3rd option which is vendor 
> color matching, which is a proprietary option).
>
> CUPS itself is just a manager of data. It does no conversion. Once the 
> PDF spool file is written, CUPS facilitates the sequential processing 
> of the spool file to get it to its intended destination in a form that 
> the printer can consume. So again CUPS is just a manager. On OS X, 
> generically for a desktop inkjet printer: it will hand the PDF onto a 
> system defined rasterizer, which in this case is cgpdftoraster filter. 
> That binary code basically calls in Core Graphics and ColorSync to do 
> color management and rasterization. CUPS then hands the raster file 
> off (per the PPD requesting this) onto rastertoescp filter, which 
> converts the raster into ESC/P commands.
>
> A gutenprint driver on Mac OS X also leverages cgpdftoraster but then 
> uses different filters, obviously, than Epson's, the rest of the way.
>
>
>
>
>> If such mappings are managed outside CUPS e.g. via Oyranos or Gnome 
>> Color Manager, it is not a must for ICC aware print workflow usind 
>> CUPS as transport mechanism.
>> For the enduser, the presentation of different printer driver 
>> settings from e.g. Gutenprint in the Printing UI could be realized 
>> without  CUPS through the LINUX OpenPrinting Dialogue as an 
>> individual option.
>
> Ask who is going to build the drivers before something else gets 
> implemented. Gutenprint does leverage *cupsICCProfile, although just 
> as defaults for grayscale, RGB and CMYK.
>
> If the drivers are never going to automatically help the user pick a 
> profile for a print condition, and there won't be some canned profiles 
> for these conditions, then further use of *cupsICCProfile is indeed 
> pointless.
>
> In any event, manual selection of an ICC profile (a custom one 
> presumably) is something that's outside of the PPD, supplied in the 
> print dialog by whatever generates that dialog (application? standard 
> system dialog?) and that needs to be captured so the profile is 
> included in the PDF print spool file.
>
> The conversion using that profile happens downstream by Ghostscript 
> along with rasterization. Then CUPS moves the color managed raster 
> file along to another filter for either display (maybe using a tiff 
> filter) or to the printer.
>
>
>
> Chris Murphy
>
>
> _______________________________________________
> openicc mailing list
> openicc at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/openicc


-- 
----------  Please note the new adress --------------

homann colormanagement --------- fon +49 30 611 075 18
Jan-Peter Homann ------------ mobile +49 171 54 70 358
Cotheniusstr. 3 -------- http://www.colormanagement.de
10407 Berlin -------- mailto:homann at colormanagement.de


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/openicc/attachments/20110207/dac9650b/attachment.htm>