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

[Jan-Peter Homann]

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".
Every colormanagement aware application which creates an PDF should be 
able to embedd the document colorspace as Output Intent into the PDF-file

Poppler should be able to read the Output Intent of a PDF and embedd 
this profile into the rasterized file.

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

Regards
Jan-Peter



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