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

[Kai-Uwe Behrmann]

Am 06.10.08, 13:44 -0700 schrieb 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).

It would make sense to me, that this object applies especially to the 
device colour spaces. E.g. so retargeting would allow for a conversion
from a deviceCMYK colour space of one printing device to say a proofing 
device. Including the answere of Graeme, I hope we are all in sync ;-)
  
> > 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.

This part affects the blending colour space. Different renderers on 
different systems might prefere different rendering colour spaces. From a 
end to end colour expectation, this still would make sense. Even though 
mixed colour space documents are possible with Ghostscript.

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

As I see, the issue remains, as a complete control would only be given if 
the gamut mapping could be controled.
What about retargetting. Will CUPS be made thinking it is "clever" and 
touches on deviceCMYK to move to a different output colourspace? Why not?
What are the rules to print real Cmyk numbers? - a missing output intent 
object? Would be logical - deviceCMYK keeps deviceCMYK.
Please correct if the PDF spec says otherwise.

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

The aspect of centralisation is still not covered. Instead of having one
good profile installed near the printer, all remote PDF producers need 
their own ICC profile for that device and if not ... ask the 
administrator.

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

This should be transparent to applications and common printing dialog 
(CPD) users. In case a app delivers a output profile use this. If not, 
provide a check box, or a equivalent, to set one by CPD, probably 
selectable.

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

This appears to me as a kind of retargetting, whether to a proofer or to a
monitor seems secondary.

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

I would guess that these go for generic GPU colour transforms. So it would 
be on hardware, which is required to be supported over shaders by each 
normal desktop driver.

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

Hope this can be improved over time.

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

The worst in this design is that, in order to print untouched Cmyk CUPS 
required one has to provide the cupsICCProfile specified profile. This 
goes in circles as it clearly strikes platform independence.

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

kind regards
Kai-Uwe Behrmann
-- 
developing for colour management 
www.behrmann.name + www.oyranos.org