[Openicc] [argyllcms] Re: Re: OT: PDF frustration

[Hal V. Engel]

On Monday 06 October 2008 10:11:13 Jan-Peter Homann wrote:
> hello List, Till and and Kai-Uwe,
> (Please take in considertaion, that I´m not a developer for the
> following text...)
>
> As I wrote in earlier e-mails, I firstly recommend to concentrate on
> implementing CMS on "flat color document / files". This means, that one
> profile is valid for the whole file / document.
> This allows to apply colormanagement after rasterization for output at
> the monitor or to the printer.
>
> Concerning PDF, the approbiate place for embedding a profile describing
> the colorspace of the PDF is the "Output Intent".

Having looked at the PDF spec this is not the color space of the PDF file 
contents but the target color space for the device that will be used for final 
output (just to avoid confusion).  Each object in a PDF file can have 
different color characterization information.  This includes ICC profiles but 
also other characterization types are allowed (device space, Lab...).  In 
addition, I think that the spec also allows for there to be a single ICC 
profile (or other color space type) that is specified for the PDF file for all 
of it's contents (I would have to review the specification again to make sure 
that this is correct).

> Every colormanagement aware application which creates an PDF should be
> able to embedd the document colorspace as Output Intent into the PDF-file

Wouldn't these applications specify the color spaces used by the various 
objects in the PDF document in the normal way as per the PDF specification 
rather than using the output intent object?  I think it would be better to use 
the Output intent object for it's intended purpose (IE. specifying the output 
color space and rendering intent).
 
>
> Poppler should be able to read the Output Intent of a PDF and embedd
> this profile into the rasterized file.

It should but it does not as it currently does not even come close to 
implementing this part of the PDF specification.   In fact none of it's "CIE 
Based" (this includes ICC profiles and other CIE based color spaces like Lab) 
color conversions are done in a way that meets the specification. 

Among the concerns that were raised when there was a lengthy thread about 
printing and CUPS on this list was that CUPS did not really support user 
selected output ICC profiles in a way that would actually work for users and 
had no way to specify rendering intent.  There are also issues with the CUPS 
design with respect to user applications finding out what profiles are 
available on the CUPS server that will require new CUPS interfaces to make the 
current CUPS design usable.  In addition for networked CUPS servers there is 
no way for user applications to get copies these profiles for things like soft 
proofing.   

With the move to a PDF based printing work flow I think we can address most of 
these concerns in one fell swoop assuming that the PDF to raster library used 
is full featured and meets the existing PDF specifications with regard to 
color management.

1. Compound color space documents will become a non-issue since this is part 
of the PDF specifications.

2. The output profile and rendering intents information can be passed as part 
of the PDF making most of the current short comings of how CM is handled by 
CUPS a non-issue.  This will allow for user selected profiles without the need 
for CUPS to provide new interfaces.  And it will also allow users to specify 
rendering intents.

3. This does not change that there is no way for user applications to query 
CUPS to get a list of non-PPD specified profiles from the server or get to 
copies of CUPS installed profiles.  But I think it makes it a non-issue since 
these profiles will no longer need to be installed in the CUPS servers 
profiles directory since output profiles can now be passed in the PDF file.

There are still lots of additional details that will need to be resolved.  For 
example does the application creating the PDF file for printing specify the 
Output profile and rendering intents or does this functionality belong in the 
CPD?  Personally I vote for this being in the CPD since it would make printer 
CM available to all applications. 

>
> Colormanagement aware drivers for Output at the monitor or the printer
> should read the embedded profile from the rasterized file and convert it
> to the output device.

I agree with this for printers but for monitors these apps should get the 
system specified profiles for those monitors (on X11 systems the _ICC_PROFILE 
atom(s)).  In addition it is generally not the video drivers that handle CM 
for monitors.  In fact all of the existing X11 and Windows video drivers are 
CM dumb and I suspect that the same thing is true for OS/X.

> As for printers, the output device is a combination of printer model/
> driver settings/media, the definition of the correct device-profile is
> better done in drivers like Gutenprint, than everywhere else.

The new (V 5.2.x) GutenPrint PPD files now have the CUPS setting for 
specifying ICC profiles - cupsICCProfile.  The last time I looked at these 
(about a month ago) these had the correct values for a set of generic profiles 
for an OS/X system but incorrect values for other *nix systems since these 
specified a file location that does not exist on any of these systems, some of 
the profiles specified are not present on most systems and none of these are 
provided with the driver.

The cupsICCProfile setting in the PPD files can specify the output color space 
type (RGB, CMYK, Gray), resolution and media settings.  Since it is part of 
the PPD file this implies that it is specific to the printer model.  So this 
appears to meet some of Jan_Peters requirements.  But there are significant 
issues with cupsICCProfile since PPD files:

1. Are static.
2. Are designed to be under the control of the device or driver vendor.
3. Are not end user modifiable (IE. only super users may change these under 
normal conditions).  
4. User modifications are lost any time the PPD file is updated by a driver 
update.

There is currently no way to disable the use of these PPD specified profiles 
so that users can print profiling targets or use user specified profiles that 
are not already in the CUPS profiles directory.  This issue will need to be 
resolved as part of the move to a color managed PDF based printing work flow.

Another issue is that currently none of the existing *toraster CUPS filters 
implement this feature set which masks many of the issues listed above.  
Hopefully this will be fixed at some point for the new pdftoraster filter.

>
> Regards
> Jan-Peter

Also having looked in more detail it appears that the GhostScript team has 
committed to having full support for ICC profiles (and I would hope all CIE 
Based color spaces) around Feb. 2009.  In addition, Till has started work on 
moving the Common Printing Dialog and the pdftoraster CUPS filter to use 
GhostScript.   IMO this is all great news and tells me that this is moving in 
the right direction and doing so fairly quickly at this point.   Till thank 
you for responding so quickly to my earlier input about these issues.

Hal

>
> Till Kamppeter wrote:
> > Hi,
> >
> > I am Till Kamppeter, leader of the OpenPrinting project at the Linux
> > Foundation.
> >
> > As most of you know, one of the projects of OpenPrinting is replacing
> > PostScript by PDF as standard print job format. Perhaps this has made
> > this thread come up.
> >
> > Here is a page with everything about the PDF printing workflow:
> > Motivation, how to set it up, and many links:
> >
> > http://www.linuxfoundation.org/en/OpenPrinting/PDF_as_Standard_Print_Job_
> >Format
> >
> > In Ubuntu Intrepid I have already implemented the PDF printing workflow.
> >
> > One piece to get a PDF printing workflow on a CUPS-based Linux/Unix
> > system are the ...topdf, pdftopdf, pdfto... CUPS filters, which Koji
> > Otani (BBR Inc. Japan) and Tobias Hoffmann (Google Summer of Code) have
> > written. Otanis-san has written all his filters based on Poppler,
> > including pdftoraster.
> >
> > Kai-Uwe, as you told in your posting we can expect full color management
> > support earlier in Ghostscript than in Poppler. Therefore I started to
> > create a pdftoraster filter based on Ghostscript. Unfortunately, the
> > "cups" output device of Ghostscript or the PDF interpreter of
> > Ghostscript have a bug which prevents Ghostscript from rendering PDF
> > with the "cups" output device. With PostScript input it works perfectly.
> > I have filed a bug report at Ghostscript:
> >
> > http://bugs.ghostscript.com/show_bug.cgi?id=690101
> >
> > If anyone volunteers for fixing this bug, I will happily upload the fix
> > into Ghostscript's SVN repository and replace Otani-sans pdftoraster by
> > my pdftoraster.
> >
> >     Till
> >
> > Kai-Uwe Behrmann wrote:
> >> Am 04.10.08, 11:44 -0700 schrieb Hal V. Engel:
> >>> handle it at the application level (like today).  The sad part about
> >>> this is that ghostscript already has some CM capabilities thanks to
> >>> Graeme and the ghostscript team is in the process of implementing
> >>> complete support.  A PDF to raster CUPS filter based on ghostscript
> >>> instead of poppler would likely have had full CM support long before
> >>> most users systems had been converted to a PDF based printing work flow
> >>> and all of these systems would have had CM by default at that point as
> >>> part of the printing system.
> >
> > _______________________________________________
> > openicc mailing list
> > openicc at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/openicc