| Summary: | decoder fails on image with YCCK colourspace causing inverted colours when printing from eog | ||
|---|---|---|---|
| Product: | cairo | Reporter: | Allan Dyer <adyer> |
| Component: | pdf backend | Assignee: | Adrian Johnson <ajohnson> |
| Status: | RESOLVED DUPLICATE | QA Contact: | cairo-bugs mailing list <cairo-bugs> |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | problem image, prints with inverted colours from eog viewer | ||
|
Description
Allan Dyer
2015-11-20 06:09:05 UTC
*** This bug has been marked as a duplicate of bug 80719 *** bug 80719 is marked as a duplicate of bug 68965, shouldn't this be marked as another bug 68965 duplicate? Also, my problem manifested in eog, eog is dependant on libcairo2 and is not dependant on poppler, so it could not be affected by bug 80719 which is a poppler bug. *** This bug has been marked as a duplicate of bug 68965 *** Re-opening. I saw the comment about it being broken in print preview which is a rendering of the pdf output from cairo and as you are using old versions assumed it was bug 80719. I suggest eog should avoid supplying non standard jpegs to cairo. There is little value in cairo embedding them in pdfs since poppler will strip them out (see bug 80719). avoiding supplying non standard jpegs to cairo is not a solution to the human problem. My user received a jpeg from a third party, opened it in the default viewer (eog) and tried printing it. Telling the user, "The problem's fixed, it doesn't print inverted, it just doesn't print" does not help them. Apparently, these YCCK colourspace images are created by Photoshop, so they are probably not uncommon. 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. 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). eog RESOLVED:NOTGNOME versus libcairo RESOLVED:NOTABUG Please compromise on a working solution. (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). |
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.