Bug 32746

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!