[Openicc] [argyllcms] OT: PDF frustration

[Hal V. Engel]

On Saturday 04 October 2008 08:42:44 Lars Tore Gustavsen wrote:
> Sorry to post this here, but I just have to get out some frustration.
> A few days ago I downloaded the new gimp 2.6. In that version it was a
> "print preview" function that sends the raster image to a pdf file for
> a preview. On my system pdfs are handled by a program called evince.
> Anyway I ended up with a crazy looking pdf file since my image was not
> in sRGB color space.  -"They have forgotten to add the right profile
> to the pdf" was my first impression. My impression was correct after
> some checking, but unfortunately the problem was much larger. Evince
> is built on a library called poppler and they don't support color
> management.
> The situation on linux today is that we can create a color managed pdf
> files with scribus, but we have now possibility to print it correctly
> in linux. Thats sad. I also found out that Kai-Uwe have already bug
> reported this. http://bugs.freedesktop.org/show_bug.cgi?id=17499 and
> Hal have written a few very nice posts on the poppler mailing list.
> http://www.nabble.com/Color-Management-td18862333.html
> The poopler developer have of course better thing to do (And I don't
> blame them), and acroreader for linux does not support color
> management. Could this be an idea for student project or something
> like that?
>
> If you don't understand what I'm talking about try to open this pdf on
> a linux system
> http://ltgustavsen.googlepages.com/pdftest3.pdf

Actually the problem is even worse with regard to poppler.  The new Common 
Printing Dialog (CPD) that is being worked on by the printing community and 
that will be a standard "feature" of many Linux distros in the not too distant 
future will only accept PDF files for preview and printing and it does all of 
it's processing using poppler.  In addition at some point all linux/unix 
printing work flows will be  PDF based rather than using PostScript.  As part 
of the conversion from PostScript to PDF a new PDF to raster CUPS filter is 
being developed by the printing community (it is currently a 0.4.x version and 
is mostly working other than CM) and it is also based on poppler. This means 
that until CM in poppler is fixed or the CUPS PDF to raster filter is 
rewritten to use a pdf to raster library with CM support that there will be no 
color managed printing work flows in Linux/Unix systems other than those that 
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.  

The real question is what do we do about it?  I have also been in contact with 
the printing community about this and there seems to be little interest in 
converting to ghostscript for either the CPD or the new CUPS pdftoraster 
filter.  In addition poppler is widely used in various viewers such as Evince 
and Okular which means that the problem is more wide spread than just these 
new printing work flows.  It could very well be a good idea to try to work 
with the poppler team to implement CM in the poppler library since this would 
correct this issue across a wider range of situations for users.  For some 
reason I never received the last note in the thread about this on the poppler 
email list.  So I was not too sure if they were receptive or not to getting 
some help implementing CM.  But it appears that they are.  Having looked at 
the poppler code in some detail a few months ago I have some idea of what 
would be involved in implementing CM.  It would not be a small project in part 
because the code is currently poorly structured to support this (IE. some 
parts of the code would be need significant work to get it ready to add CM 
support) but would be something that could be at least mostly done by a Google 
Summer of Code type project (IE. one person full time for around 3 months).  
In other words I think Lars' idea of a student project is a good one.   But I 
am not sure how to go about organizing an effort like that.  

One possibility is to have an OpenICC proposal for this as part of the 2009 
Google Summer of Code but there are a number of issues with this.  First it 
means that the soonest we would see this fixed in poppler would be around this 
time next year.  Second we have no way of knowing if Google will select the 
OpenICC again for next years program.   And finally we would not have any way 
to assure that a student would be interested in this project and that this 
project would be make the cut even if OpenICC were accepted by Google for 
2009. 

Although Lars vented about this here I think this belongs on the OpenICC list 
so I am cross posting my reply to the OpenICC list.  I think there are things 
we can do to help the poppler project with this issue and I think that there 
are others on OpenICC that might be able to suggest ways to approach this.   
My last note to the poppler email list has some rough ideas about what needs 
to be done and it could be used as a basis for a series of smaller projects 
that could move poppler along in the desired direction.  This might make it 
easier to find student volunteers for since these sub-projects would be 
something that would be more approachable for a student. 

One other thing.  Lars has a link in his note to a bug opened by Kai-Uwe about 
three weeks ago but there is an existing CM bug open for poppler that was 
opened 02/16/2008  https://bugs.freedesktop.org/show_bug.cgi?id=14526 .  I am 
not sure why the Kai-Uwe bug is not closed as a duplicate of that bug. 

Hal