<html>
    <head>
      <base href="https://bugs.freedesktop.org/" />
    </head>
    <body>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_REOPENED "
   title="REOPENED - decoder fails on image with YCCK colourspace causing inverted colours when printing from eog"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=93031#c8">Comment # 8</a>
              on <a class="bz_bug_link 
          bz_status_REOPENED "
   title="REOPENED - decoder fails on image with YCCK colourspace causing inverted colours when printing from eog"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=93031">bug 93031</a>
              from <span class="vcard"><a class="email" href="mailto:friemann@gnome.org" title="Felix Riemann <friemann@gnome.org>"> <span class="fn">Felix Riemann</span></a>
</span></b>
        <pre>(In reply to Adrian Johnson from <a href="show_bug.cgi?id=93031#c6">comment #6</a>)
<span class="quote">> 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.</span >

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.

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

>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:
<a href="https://forums.adobe.com/thread/975777">https://forums.adobe.com/thread/975777</a>

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).</pre>
        </div>
      </p>
      <hr>
      <span>You are receiving this mail because:</span>
      
      <ul>
          <li>You are the QA Contact for the bug.</li>
      </ul>
    </body>
</html>