[Openicc] [argyllcms] Re: Re: OT: PDF frustration
Jan-Peter Homann
homann at colormanagement.de
Tue Oct 7 00:27:59 PDT 2008
Hello all,
Some comments inline
Hal V. Engel wrote:
> 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).
>
>
The PDF specs several kinds of color definitions per object and per
document. The concept to firstly concentrate on one profile for the
document would guide the PDF generating applications either to generate
a PDF-file DeviceRGB objects with an RGB-profile as output intent or a
PDF-file with DeviceCMYK and DeviceGray and a CMYK-profile as output intent.
Concerning an RGB-workflow based on sRGB, the user expects on different
output devices to have all colors be sRGB. So specifying sRGB as output
intent matches both the user expectations and is valid according the PDF
specs.
One possible source of the different color output from GIMP with PDF
export and poppler is may be, that GIMP creates ICCbasedRGB PDF objects,
which are wrong interpreted by poppler. If GIMP instead would create
DeviceRGB objects with embedding sRGB as OutputIntent, poppler will not
do any colormanagement on individual objects of the PDF file.
Even if poppler is not able to embedd the sRGB profile in the rasterized
bytemap for the monitor or the printer, this causes no problem, if the
monitor and printer default settings for non tagged RGB files are set to
sRGB.
The solution of the problem differnt color GIMP / poppler would be, that
GIMP should create DeviceRGB PDF-objects instead of ICCbasedRGB !
This would lead to three levels of colormanagement complexity in
RGB-based workflows with PDF as internal format:
1) sRGB only workflow:
PDF-generation is always DeviceRGB, the PDF-libraries like poppler do
not need any colormanagement support. Mmapping from sRGB to output is
done outside the PDF library. In case of the monitor it could may be
complete outside the computer, if the monitor has an sRGB setting.
2) Output Intent centered workflow
The PDF generating applications generating only DeviceRGB or DeviceCMYK
/ DeviceGray PDF objects and embedding the output intent
The PDF library and the Raster process have to communicate, that the
Output Intent is embedded after rasterization. Colormanagement for the
monitor must be done inside the computer from the colorspace of the
rasterized Bytemap to the monitor profile.
3) PDF complete colormanagement workflow
The PDF library supports colormanagement on object level. This includes
espacially conversions from the object colorspace to the output intent
and the handling of transparencies between objects, which may have
different embedded profiles. It also needs to handle differnt embedded
rendering intents for individual objects. Concerning embedded relative
colorimetric intents in individual objects, it would be very helpful, to
have the option to activate blackpoint compensation, but the PDF specs
currently have no definition, where in the PDF-file this can specified.
Furthermore, ICCbased transformations from CMYK to CMYK are often not
delivering high-quality results, so may be the option to decativate CMYK
to CMYK transformations on object level is often asked from the users
in the graphics arts....
Result: Colormanagement on the level of individual PDF objects is a "Can
of worms"...
But this could be solved e.g. by the strategy, that poppler triggers
direct rasterizing only if ALL PDF-objects are DeviceRGB or DeviceCMYK /
Device Gray. If the PDF file conatiand at least one ICCbased object,
poppler uses GhostScript for rasterizing both to the monitor or for
print output.
Regards
Jan-Peter
>> 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
>>>
>
> _______________________________________________
> openicc mailing list
> openicc at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/openicc
>
>
More information about the openicc
mailing list