GNOME Bugzilla – Bug 758155
Image prints with incorrect dark background and displays the same in Print Preview
Last modified: 2016-10-08 15:53:50 UTC
OS Ubuntu 14.04.3 LTS eog Version: 3.10.2-0ubuntu5 Attached image is displayed normally, but is printed with a dark background and has a dark background in Print Preview. The same image prints correctly from GIMP.
The problem image is 3.3MB, how can I provide that for testing?
If you don't have access to some webspace or cloud space (Dropbox, Owncloud, ???) you can send it to me by email. Hover over my name above this comment and it will tell you my address. Please reference this bug, so I know what's going on.
Okay, got your picture and took a look. The JPG is not in the "traditional" RGB colorspace but uses CMYK instead. eog does not support that color space. However, gdk-pixbuf (the library that decodes the JPG for eog) recognizes the format and automatically attempts a simple (because a full/more correct one would require ICC profiles) conversion to RGB. But it doesn't tell eog it did so. Anyway, as the image data is converted eog is able to display the file just fine. Now to the printing. During printing the image is embedded into a PDF file that is sent to your printer. The PDF is produced by libcairo. When printing JPGs eog uses a special feature of libcairo, that simply embeds the JPG data into the PDF, which avoids an otherwise necessary recompression step and keeps the filesize low. Embedding the JPEG data into a PDF produces a few fields in the file later telling the viewer the size of the image and its colorspace. Looking at the produced PDF, libcairo did in fact detect that your file is a CMYK file. So far so good. The catch is that your image is not in the "pure" CMYK colorspace but in the inverted variant that Photoshop writes, called YCCK. This causes the inverted colors, if the decoder doesn't respect that. This is realized by adding a special color transform to the image object in the PDF and that is the part that is missing here. If I manually insert the necessary command into the PDF it renders correctly. It would be great if you could report this to the libcairo developers as that needs to be fixed in libcairo's pdf backend. See also: https://forums.adobe.com/thread/975777 --- Thanks for taking the time to report this. However, this application does not track its bugs in the GNOME GNOME Bugzilla. We kindly ask you to report the bug to the application authors. For a selective list of other bug tracking systems please consult https://wiki.gnome.org/Bugsquad/TriageGuide/NonGnome. If the affected third party application has a bug tracking system you should investigate whether a bug for the reported issue is already filed in this system. If it has not been filed yet please do so. Also ensure that both bug reports contain a link to each other. Thanks in advance!
Reported to freedestop.org : https://bugs.freedesktop.org/show_bug.cgi?id=93031 with a link to this bug.
libcairo developer has responded that this is eog's fault for not supplying standards-complaint data: "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.
This has been fixed in cairo's master-branch: https://bugs.freedesktop.org/show_bug.cgi?id=97612 A quick check with your sample shows that cairo now automatically adds the necessary filter to the PDF. It appears to be unreleased yet though. Thanks for taking the time to report this.