Created attachment 119966 [details] problem image, prints with inverted colours from eog viewer See https://bugzilla.gnome.org/show_bug.cgi?id=758155 Attached image is displayed normally by the Eye of Gnome (eog) viewer, but is printed with a dark background and has a dark background in Print Preview. The same image prints correctly from GIMP. Reported as eog bug, Felix Riemann responded that the problem was in libcairo: "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." OS Ubuntu 14.04.3 LTS eog Version: 3.10.2-0ubuntu5 libcairo2 Version: 1.13.0~20140204-0ubuntu1.1
*** 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).
*** This bug has been marked as a duplicate of bug 97612 ***
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.