[cairo-bugs] [Bug 93031] decoder fails on image with YCCK colourspace causing inverted colours when printing from eog

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=93031

--- Comment #8 from Felix Riemann <friemann at gnome.org> ---
(In reply to Adrian Johnson from comment #6)
> eog supplies both the uncompressed image data and compresses jpeg data. If
> eog avoids supplying the non standard compressed jpeg, the uncompressed
> image data will print correctly.

Well, eog could do that, but that's not actually solving the problem but is
merely a workaround as PDF renderers are actually able to handle such images
(see below).

eog uses the metadata feature for printing to keep the filesize low where
possible, as we had reports of printers chocking on the large deflate-based
PDFs. Also it is a bit complicated for eog to detect the image format as it
already receives the image data preconverted to RGB from gdk-pixbuf.

> The cairo documentation states the the jpeg data must comply with ISO/IEC
> 10918-1
> (http://www.cairographics.org/manual/cairo-cairo-surface-t.html#CAIRO-MIME-
> TYPE-JPEG:CAPS).

>From my understanding Allan's file complies to that standard, because the
standard makes no assertions on the colorspace at all (it explicitly says so in
the first chapter). Also PDF readers are able to handle such images just fine
if they are told how to interpret the color components:
https://forums.adobe.com/thread/975777

If I add the mentioned decode array in the cairo-created PDF by hand in my text
editor the file renders correctly in Adobe Reader and Evince (I don't
understand what poppler is supposed to strip out here).

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cairographics.org/archives/cairo-bugs/attachments/20151121/fea4fad0/attachment.html>