On 12/30/2010 01:47 AM, George Liu wrote: > Till, > > I discovered a printing problem from the Document Viewer 2.32.0 (using > poppler/cairo 0.14.3) on Ubuntu 10.10. > > When print the attached 4-page PDF file from this application, the > 3rd page became grayscale, the 4th page did not print the image on > the left side. > > I checked CUPS error log, it seems that the application submitted pdf > file to CUPS. (and I’m using a Postscript Ricoh color printer > Ricoh-Aficio_MP_C3500PS) > > However, when I print the pdf file from command line, the image prints > fine.(so the problem is not created by CUPS) > > So, I suspect the poppler/cairo library is created a distorted pdf > file while printing. > > Are you aware of similar problems? > > George > I did not get a thing like that, most problems are too slow rendering of Evince's PDF output by Ghostscript as Evince produces a very big awkward PDF. I have tested (on Natty) by opening the original.pdf with evince and printing to a file in PDF format. The output file shows exactly what you reported, And this is really not a problem of CUPS and its filters as CUPS is not involved when printing to a file with Evince. The PDF output is generated by Cairo, so you should report a bug to Cairo. Please report the bug on http://bugs.freedesktop.org/ and choose "cairo" as the product. Please send me a link to the bug report. Have a great 2011. Till
Created attachment 41535 [details] Page 3 of the original pdf file
Created attachment 41536 [details] Page 4 of the original pdf file
Created attachment 41537 [details] Print to File for the original page 3. It looks like the greenish color in original file was treated as black
Created attachment 41538 [details] Print to File for the original page 4. It looks like the light greenish color in original file was treated as white
The problem is the color space in the PDF file for the JPEG2000 images is different to the color space embedded in the JPEG2000 images. As cairo doesn't support color spaces the cairo API does not provide a way to override the color space of the JPEG2000 mime data. The workaround is to make poppler disable embedding JPEG2000 mime data when a color space is specified in the stream dictionary.
Created attachment 41539 [details] [review] disable jpx mime-data if stream dict specifies a cs Patch to fix this.
Or it could strip the color space information from imbedded jpeg data. Note that the user was happy with the screen appearance where cairo ignored the color space information. This is pretty typical, I have usually found it better to ignore this info than to do anything with it. bugzilla-daemon@freedesktop.org wrote: > https://bugs.freedesktop.org/show_bug.cgi?id=32746 > > Adrian Johnson <ajohnson@redneon.com> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Product|cairo |poppler > Version|1.10.3 |unspecified > Component|pdf backend |cairo backend > AssignedTo|ajohnson@redneon.com |poppler-bugs@lists.freedesk > | |top.org > QAContact|cairo-bugs@cairographics.or | > |g | > > --- Comment #5 from Adrian Johnson <ajohnson@redneon.com> 2010-12-30 17:49:05 PST --- > The problem is the color space in the PDF file for the JPEG2000 images is > different to the color space embedded in the JPEG2000 images. > > As cairo doesn't support color spaces the cairo API does not provide a way to > override the color space of the JPEG2000 mime data. The workaround is to make > poppler disable embedding JPEG2000 mime data when a color space is specified in > the stream dictionary. >
On 01/01/11 07:46, Bill Spitzak wrote: > Or it could strip the color space information from imbedded jpeg data. The Color Specification box in JPEG2000 is mandatory. > Note that the user was happy with the screen appearance where cairo > ignored the color space information. This is pretty typical, I have > usually found it better to ignore this info than to do anything with it. The color space is not ignored in the screen rendering. Poppler is using the color space specified in the PDF stream dictionary when decoding the JP2 image. In this case the JP2 is a black and white image and the PDF color space specified for the image is a DeviceN color space containing green and black. On screen the image is green and black but when printed the image is black and white. Ignoring the color space is not an option as without it the printed image does not look even remotely like the screen image. > bugzilla-daemon@freedesktop.org wrote: >> https://bugs.freedesktop.org/show_bug.cgi?id=32746
Comment on attachment 41539 [details] [review] disable jpx mime-data if stream dict specifies a cs >+ // colorspace in stream dict may be different from colorspace in jpx >+ // data >+ if (str->getKind() == strJPX) { >+ if (str->getDict()->lookup("ColorSpace", &obj)) This is always true, since Dict returns a null object (obj->initNull()) when the key is not found. Also obj should be freed.
Created attachment 41596 [details] [review] Update Adrian's patch Adrian, could you try this patch to make sure it fixes the problem for you?
(In reply to comment #10) > Created an attachment (id=41596) [details] > Update Adrian's patch > > Adrian, could you try this patch to make sure it fixes the problem for you? works for me
Pushed to both branches, thanks!
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.