[argyllcms] Re: OT: PDF frustration
- From: "Hal V. Engel" <hvengel@xxxxxxxxxxx>
- To: argyllcms@xxxxxxxxxxxxx, openicc@xxxxxxxxxxxxxxxxxxxxx
- Date: Sat, 4 Oct 2008 11:44:15 -0700
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
Other related posts:
