Bug 32746 - poppler/cairo creates distorted pdf print file
Summary: poppler/cairo creates distorted pdf print file
Status: RESOLVED FIXED
Alias: None
Product: poppler
Classification: Unclassified
Component: cairo backend (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: poppler-bugs
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-12-30 09:34 UTC by george.liu
Modified: 2011-01-04 02:50 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Page 3 of the original pdf file (450.12 KB, application/pdf)
2010-12-30 09:57 UTC, george.liu
Details
Page 4 of the original pdf file (304.63 KB, application/pdf)
2010-12-30 09:57 UTC, george.liu
Details
Print to File for the original page 3. It looks like the greenish color in original file was treated as black (450.12 KB, application/pdf)
2010-12-30 09:58 UTC, george.liu
Details
Print to File for the original page 4. It looks like the light greenish color in original file was treated as white (213.66 KB, application/pdf)
2010-12-30 09:59 UTC, george.liu
Details
disable jpx mime-data if stream dict specifies a cs (2.91 KB, patch)
2010-12-30 17:52 UTC, Adrian Johnson
Details | Splinter Review
Update Adrian's patch (2.97 KB, patch)
2011-01-03 11:41 UTC, Carlos Garcia Campos
Details | Splinter Review

Description george.liu 2010-12-30 09:34:24 UTC
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
Comment 1 george.liu 2010-12-30 09:57:17 UTC
Created attachment 41535 [details]
Page 3 of the original pdf file
Comment 2 george.liu 2010-12-30 09:57:45 UTC
Created attachment 41536 [details]
Page 4 of the original pdf file
Comment 3 george.liu 2010-12-30 09:58:43 UTC
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
Comment 4 george.liu 2010-12-30 09:59:31 UTC
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
Comment 5 Adrian Johnson 2010-12-30 17:49:05 UTC
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.
Comment 6 Adrian Johnson 2010-12-30 17:52:51 UTC
Created attachment 41539 [details] [review]
disable jpx mime-data if stream dict specifies a cs

Patch to fix this.
Comment 7 Bill Spitzak 2010-12-31 13:16:38 UTC
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.
>
Comment 8 Adrian Johnson 2011-01-01 03:54:57 UTC
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 9 Carlos Garcia Campos 2011-01-03 11:38:30 UTC
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.
Comment 10 Carlos Garcia Campos 2011-01-03 11:41:03 UTC
Created attachment 41596 [details] [review]
Update Adrian's patch

Adrian, could you try this patch to make sure it fixes the problem for you?
Comment 11 Adrian Johnson 2011-01-04 00:13:09 UTC
(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
Comment 12 Carlos Garcia Campos 2011-01-04 01:19:54 UTC
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.