Re: [Printing-architecture] poppler vs. GhostScript & color management

Re: [Printing-architecture] poppler vs. GhostScript & color management

[Till Kamppeter]

Hal, thank you very much for your posting. This is a very important point.

I think under these circumstances we should switch all PDF rasterization 
to Ghostscript. Otani-san, can you change the pdftoraster (and if needed 
also the pdftopdf filter) to be based on the Ghostscript library libgs? 
Lars, Alex, can you make the preview of the printing dialog be 
libgs-based? Tobias, Hin-Tak, can you do the appropriate changes on 
pdftoijs?

We do not need to rush this into Intrepid or into the GSoC, but at some 
point we should be standards-conforming as far as possible and we should 
also support color management.

Ghostscript developers, what are the plans for support for handling all 
"CIE based" objects using CIE compliant techniques and ICC profiles in 
Ghostscript 8.64?

    Till

Hal V. Engel wrote:
>  From looking at the code for the new pdftoraster filter that is under 
> developement it appears that it, like the Common Printing Dialog, uses 
> poppler as it's pdf rasterization library. Inspecting the poppler code I 
> discovered that it is not compliant with any of the published PDF 
> specifications which require support for handling all "CIE based" 
> objects using CIE compliant techniques. This includes support for ICC 
> profiles imbedded in the PDF files as well as ICC profiles as an output 
> target. In addition inquiries made on the poppler developer email list 
> indicate that there are currently no plans to implement specifications 
> compliant support for "CIE based" objects although the developement team 
> would like to do this at some point. I was told that the code would need 
> major restructuring to add this support and looking at the code this 
> appears to be a correct assessment. In other words it will likely be a 
> long time before poppler is compliant with the PDF specification.
> 
> GhostScript on the other hand has partial support in place for "CIE 
> based" objects and user specified output color spaces with the current 
> stable version. There are currently two issues in this area. First 
> output color spaces can only be specified as a Postscript language CRD. 
> And, second, currently only ICC V2 profiles are supported.
> 
> ICC profiles can be converted into a Postscript language CRD using the 
> LittleCMS icc2ps utility and this can be passed on the command line to 
> GhostScript during the conversion from PDF to a raster format. The use 
> of Postscript language CRDs for specifying the output color space has 
> it's limitations and there are issues like banding when creating output 
> for larger gamut devices. Even with these limitations GhostScript is 
> much closer to being in compliance with the PDF specification than is 
> poppler. For details on how to setup and use GhostScript with the 
> currently supported color management workflow see 
> https://www.oyranos.org/wiki/index.php?title=Ghostscript .
> 
> In addition, the GhostScript team is in the process of doing a major 
> rework of how ICC color management works in GhostScript that should fix 
> all of the issues with the current implementation. For example it will 
> be possible to configure GhostScript to use an external CMS like 
> LittleCMS (currently it has an embedded cms library). LCMS has support 
> for both ICC V2 and ICC V4 profiles. In addition, the rework will allow 
> users to directly specify an ouput ICC profile and it will no longer use 
> an intermeadeate Postscript language CRD for the color space conversion 
> (IE. the conversion will use the installed CMS engine). See 
> http://www.ghostscript.com/pipermail/gs-devel/2008-August/007871.html 
> for more details about this.
> 
> Currently there is no indication when GhostScript will have the new ICC 
> profile features. Given the lack of support for color managment in 
> poppler is there any possibility that the new pdftoraster CUPS filter 
> and the Common Printing Dialog might convert to using GhostScript?
> 
> Hal
> 

Re: [Printing-architecture] poppler vs. GhostScript & color management

[Till Kamppeter]

We switched now from a PostScript workflow without color management to a 
PDF workflow without color management. Next step would be to have color 
management being a standard part of the printing infrastructure.

All drivers except CUPS raster drivers (IJS, Ghostscript built-in, ...) 
still use Ghostscript in the first implementation of the CUPS PDF 
workflow in Ubuntu Intrepid. Foomatic 4.0 makes it possible that PDF 
gets fed into Ghostscript and using nearly the same Ghostscript command 
lines as before.

Color management is not yet completely implemented in both renderers. It 
is really a good idea for next GSoC to do projects on making color 
management work in both Ghostscript (if GS upstream developers do not 
complete it in 8.64, due in Feb 2009) and Poppler (and also the CUPS 
imagetoraster filter).

    Till

Hin-Tak Leung wrote:
> Till Kamppeter wrote:
>> Hal, thank you very much for your posting. This is a very important 
>> point.
>>
>> I think under these circumstances we should switch all PDF 
>> rasterization to Ghostscript. Otani-san, can you change the 
>> pdftoraster (and if needed also the pdftopdf filter) to be based on 
>> the Ghostscript library libgs? Lars, Alex, can you make the preview of 
>> the printing dialog be libgs-based? Tobias, Hin-Tak, can you do the 
>> appropriate changes on pdftoijs?
> 
> I don't know enough of the other issues, but libgs and poppler being 
> substantially different in so many levels, switching from one to another is
> not trivial; also, on pdftoijs going libgs - it won't be much different
> from the existing postscript-based workflow, other than some efficiency
> advantage of a customized/dedicated libgs client vs a general ghostscript
> command-line shell-script.
> 
>> We do not need to rush this into Intrepid or into the GSoC, but at 
>> some point we should be standards-conforming as far as possible and we 
>> should also support color management.
>>
>> Ghostscript developers, what are the plans for support for handling 
>> all "CIE based" objects using CIE compliant techniques and ICC 
>> profiles in Ghostscript 8.64?
> 
> I think we have a few project ideas here for next year's GSoC :-), for both
> poppler and ghostscript...
> 
> Hin-Tak
> 
> 
> 
> 

Re: [Printing-architecture] [gs-devel] Re: poppler vs. GhostScript & color management

[Till Kamppeter]

Can everyone here with enough knowledge about color management and PDF 
standards file bugs against both Poppler and Ghostscript for everything 
which is wrong? Please attach sample PDFs to your bug reports and 
perhaps also image files (JPG, PNG, ...) which show how the output 
should look like.

    Till

Kai-Uwe Behrmann wrote:
> Hello,
> 
> first thanks to considering the colour management argument. ...
> 
> Am 02.09.08, 18:43 +0200 schrieb Till Kamppeter:
>> We switched now from a PostScript workflow without color management to a PDF
>> workflow without color management. Next step would be to have color management
>> being a standard part of the printing infrastructure.
>  
>> Color management is not yet completely implemented in both renderers. It is
>> really a good idea for next GSoC to do projects on making color management
>> work in both Ghostscript (if GS upstream developers do not complete it in
>> 8.64, due in Feb 2009) and Poppler (and also the CUPS imagetoraster filter).
> 
> In regards of a comparision I would say Xpdf has no ICC support as of 
> v3.02. 
> On a PDF with lots of different ICC colour spaces, Xpdf does get 
> only sRGB right.
> Ghostscript renders correct all those ICC profile taged images from the 
> same test PDF.
> 
> Colour people where really excited to see all the capbilities in 
> Ghostscript since v8.15 and especially 8.5x. It is good for support and 
> the over all appearance of a system to say to clients and custumers, there 
> is a CM wise working printing solution already installed on your system. 
> In the past we had often to suggest for difficult replacements or thierd 
> party products.
> 
>> Hin-Tak wrote:
>>> I think we have a few project ideas here for next year's GSoC :-), for both
>>> poppler and ghostscript...
> 
> ... and support of transparent images, which is missed in both.
> 
> kind regards
> Kai-Uwe Behrmann

Re: [Printing-architecture] [gs-devel] Re: poppler vs. GhostScript & color management

[Till Kamppeter]

Kai-Uwe Behrmann wrote:
> I've sent the below information to the respective bug trackers. 
> The web has many good resources about PDF colour management. The OpenICC 
> list is one good place to talk with people about this toppic or obtain 
> specific hints.

Can you post links to the bug reports/feature requests you have made?

    Till

Re: [Printing-architecture] poppler vs. GhostScript & color management

[Alex Wauck]

[-- Attachment #1: Type: text/plain, Size: 872 bytes --]

On Tue, Sep 2, 2008 at 9:39 AM, Till Kamppeter <till.kamppeter@gmail.com>wrote:

> I think under these circumstances we should switch all PDF rasterization to
> Ghostscript. Otani-san, can you change the pdftoraster (and if needed also
> the pdftopdf filter) to be based on the Ghostscript library libgs? Lars,
> Alex, can you make the preview of the printing dialog be libgs-based?
> Tobias, Hin-Tak, can you do the appropriate changes on pdftoijs?


I know nothing about libgs.  Ironically, now that the school year has
started, I will probably have more free time, so I can take a look at it.
No promises, though.  Given that krita, inkscape, and okular (according to
apt-cache rdepends) use Poppler, it may be wiser to improve Poppler
instead.  I  am thouroughly unfamiliar with the Poppler codebase though, so
I have no idea how difficult it would be to do so.

Alex

[-- Attachment #2: Type: text/html, Size: 1185 bytes --]