Bug 166460

Created attachment 117957 [details]
logo, possibly generated with Adobe Photoshop 7.0

*** Bug 166461 has been marked as a duplicate of this bug. ***

Are you still seeing this problem?

Yes, problem still exists on fully-updated fedora-8

Note:  I saved the attachement from #1, but needed to:
   mv attachment.cgi sickles_4c_logo.jpg
to reproduce the test case.

My printer is an: HP Officejet_Pro_K550

Please attach the PPD file you are using (/etc/cups/ppd/<queuename>.ppd).

Created attachment 296141 [details]
/etc/cups/ppd/Officejet_Pro_K550.ppd

Created attachment 296176 [details]
output of /usr/lib/cups/filter/imagetops filter

This is the output of the CUPS imagetops filter.  It shows the incorrect
colours, so the problem lies in imagetops (part of CUPS) or one of its
dependencies.

Here's the debug output of that filter.

DEBUG: Page = 595x842; 10,36 to 585,833
DEBUG: num_components = 4
DEBUG: jpeg_color_space = JCS_YCCK
DEBUG: Converting image to CMYK...
DEBUG: JPEG image 750x931x4, 128x128 PPI
DEBUG: Before scaling: xppi=128, yppi=128, zoom=0.00
DEBUG: Before scaling: xprint=8.0, yprint=11.1
DEBUG: Image size is 5.9 x 7.3 inches...
DEBUG: Auto orientation...
DEBUG: xpages = 1x5.86in, ypages = 1x7.27in
DEBUG: XPosition=0, YPosition=0, Orientation=0
DEBUG: xprint=6, yprint=7
DEBUG: PageLeft=10, PageRight=585, PageWidth=595
DEBUG: PageBottom=36, PageTop=833, PageLength=842
DEBUG: left=86.56, top=696.34
INFO: Printing page 1...

Reported upstream.

Fix has been committed upstream and will be in 1.3.7.

cups-1.3.6-3.fc8 has been submitted as an update for Fedora 8

cups-1.3.6-3.fc8 has been pushed to the Fedora 8 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update cups'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F8/FEDORA-2008-2131

cups-1.3.6-3.fc8 doesn't fix the problem, but perhaps thats because #10 says the
fix will be in 1.3.7 ?

No, it's because the back-ported fix doesn't work for some reason.  OK, thanks
for testing.

I've had another look at this, and 1.3.6-3.fc8 fixes the problem that I could
originally see.  With the new package I get a correct representation of the jpg
file in PostScript, whereas I saw wrong colours before.

If you have a separate print server, the updated package needs to be installed
on the print server not the client.

Can you please double-check that you are still seeing the problem with
1.3.6-3.fc8, and attach a test case if different from the attachment in comment
#1?  Thanks.

I thought I had responded to this already, sorry.

I retested with the same tests case from #1, on an fc8 x86_64 platform with the
printer directly attached (USB).    I still see the same problem when printing
with "lpr".   Printing from "eog" results in more reasonable colors.

using: cups-1.3.6-3.fc8.x86_64

Is there a way I can save the .ps generated by lpr to a file?

Created attachment 299921 [details]
imagetops.ps

lpr doesn't generate PostScript output itself; it submits the file as-is to
CUPS, which applies the imagetops and pstops filters to it because of its file
type.

I've attached the output I get on Fedora 8, x86_64, with cups-1.3.6-3.fc8, from
this command:

PPD=Officejet_Pro_K550.ppd /
  /usr/lib/cups/filter/imagetops 1 tim '' 1 '' < \
  sickles_4c_logo.jpg >imagetops.ps

It looks correct to me when viewing it with evince.  Please try printing it
with 'lpr imagetops.ps' and tell me if that gives you correct or incorrect
paper output.

(You will shortly see a comment here from Fedora Update System about an updated
package -- please ignore that comment.)

Created attachment 300009 [details]
image produced locally by imagetops filter

Your version of imagetops from #17 printed ok, using: lpr imagetops.ps

Running the command in #17 produced the result in #19, still wrong

If we're running the same command on the same architecture with the same inputs
and getting different outputs, either something in the environment is different
or they are different executables.

What do these commands say?:

rpm -q cups cups-libs
rpm -V cups
sha1sum /usr/lib/cups/filter/imagetops 

root@bock:~# rpm -q cups cups-libs
cups-1.3.6-3.fc8.x86_64
cups-libs-1.3.6-2.fc8.x86_64
cups-libs-1.3.6-2.fc8.i386
root@bock:~# rpm -V cups
S.5....T c /etc/cups/classes.conf
S.5....T c /etc/cups/cupsd.conf
S.5....T c /etc/cups/printers.conf
root@bock:~# sha1sum /usr/lib/cups/filter/imagetops
f001ff94625d98213b9b9e4d2bb950700022af74  /usr/lib/cups/filter/imagetops

Created attachment 300052 [details]
filter-through-imageps.tar.gz

Here is the complete test case I am using.  Please try it like this:

tar zxf filter-through-imageps.tar.gz
cd filter-through-imageps
./filter-through-imageps.sh
evince imagetops.ps

What result do you get?

evince shows the bad image.

the console shows:

ellson@bock:~> tar zxf filter-through-imageps.tar.gz
ellson@bock:~> cd filter-through-imageps/
ellson@bock:filter-through-imageps> ./filter-through-imageps.sh
DEBUG: imagetoraster - copying to temp print file "/tmp/47f380546b059"
DEBUG: Page = 595x842; 10,36 to 585,833
DEBUG: num_components = 4
DEBUG: jpeg_color_space = JCS_YCCK
DEBUG: Converting image to CMYK...
DEBUG: JPEG image 750x931x4, 128x128 PPI
DEBUG: Before scaling: xppi=128, yppi=128, zoom=0.00
DEBUG: Before scaling: xprint=8.0, yprint=11.1
DEBUG: Image size is 5.9 x 7.3 inches...
DEBUG: Auto orientation...
DEBUG: xpages = 1x5.86in, ypages = 1x7.27in
DEBUG: XPosition=0, YPosition=0, Orientation=0
DEBUG: xprint=6, yprint=7
DEBUG: PageLeft=10, PageRight=585, PageWidth=595
DEBUG: PageBottom=36, PageTop=833, PageLength=842
DEBUG: left=86.56, top=696.34
INFO: Printing page 1...
ellson@bock:filter-through-imageps> evince imagetops.ps

I think this is an fc8 only issue.

I get good images on 2 different rawhide machines, x86_64 and i386
i get bad images on 3 different fc8 machines, 2 x86_64 and 1 i386

There is a different version of cups, and /usr/lib/cups/filter/imagetops, on
rawhide:

root@ontap:~# rpm -q cups cups-libs
cups-1.3.6-7.fc9.x86_64
cups-libs-1.3.6-7.fc9.x86_64
cups-libs-1.3.6-7.fc9.i386
root@ontap:~# rpm -V cups
S.5....T  c /etc/cups/printers.conf
SM5....T  c /etc/cups/subscriptions.conf
root@ontap:~# sha1sum /usr/lib/cups/filter/imagetops
28012257a23d2e35cb62fdc2fe0dba97e1e30894  /usr/lib/cups/filter/imagetops


Could cups-1.3.6-7 be pushed to fc8?

No -- for one thing, the devel packages will break non-UTF-8 clients.  Besides,
it's no good just masking the problem if we can't identify what it is.  The only
code differences between F-8 and devel are:

* don't patch out strict UTF-8 requirement
* fix compilation against newer glibc
* allow log rotation to be performed by external program

No, I think the clue is in the output from imagetops.  Here is the output I get
from cups-1.3.6-3.fc8:

DEBUG: imagetoraster - copying to temp print file "/tmp/47f3a03d68ed0"
DEBUG: Page = 595x842; 10,36 to 585,833
DEBUG: Adobe CMYK JPEG detected (inverting color values)
DEBUG: num_components = 4
DEBUG: jpeg_color_space = JCS_YCCK
DEBUG: Converting image to CMYK...
DEBUG: JPEG image 750x931x4, 128x128 PPI
DEBUG: Before scaling: xppi=128, yppi=128, zoom=0.00
DEBUG: Before scaling: xprint=8.0, yprint=11.1
DEBUG: Image size is 5.9 x 7.3 inches...
DEBUG: Auto orientation...
DEBUG: xpages = 1x5.86in, ypages = 1x7.27in
DEBUG: XPosition=0, YPosition=0, Orientation=0
DEBUG: xprint=6, yprint=7
DEBUG: PageLeft=10, PageRight=585, PageWidth=595
DEBUG: PageBottom=36, PageTop=833, PageLength=842
DEBUG: left=86.56, top=696.34
INFO: Printing page 1...

I'm not sure why imagetops on my system would decide to invert the colours,
whereas yours won't -- however, we have already verified that the binary is the
same so let's try comparing shared library dependencies.

What do you get for 'ldd /usr/lib/cups/filter/imagetops', and for 'rpm -q
libjpeg'?  Here's what I get:

$ ldd /usr/lib/cups/filter/imagetops
        linux-vdso.so.1 =>  (0x00007fff727fd000)
        libcupsimage.so.2 => /usr/lib64/libcupsimage.so.2 (0x00002aaaaaed0000)
        libcups.so.2 => /usr/lib64/libcups.so.2 (0x00002aaaab0e7000)
        libgnutls.so.13 => /usr/lib64/libgnutls.so.13 (0x00002aaaab31e000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00002aaaab5a1000)
        libm.so.6 => /lib64/libm.so.6 (0x00002aaaab7bc000)
        libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00002aaaaba3f000)
        libaudit.so.0 => /lib64/libaudit.so.0 (0x00002aaaabc78000)
        libselinux.so.1 => /lib64/libselinux.so.1 (0x00002aaaabe8d000)
        libc.so.6 => /lib64/libc.so.6 (0x00002aaaac0a8000)
        libtiff.so.3 => /usr/lib64/libtiff.so.3 (0x00002aaaac400000)
        libpng12.so.0 => /usr/lib64/libpng12.so.0 (0x00002aaaac659000)
        libjpeg.so.62 => /usr/lib64/libjpeg.so.62 (0x00002aaaac87d000)
        libz.so.1 => /lib64/libz.so.1 (0x00002aaaaca9f000)
        libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x00002aaaaccb3000)
        libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x00002aaaacee1000)
        libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x00002aaaad174000)
        libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00002aaaad399000)
        libgcrypt.so.11 => /lib64/libgcrypt.so.11 (0x00002aaaad59b000)
        libgpg-error.so.0 => /lib64/libgpg-error.so.0 (0x00002aaaad7e9000)
        /lib64/ld-linux-x86-64.so.2 (0x00002aaaaacb4000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00002aaaad9ec000)
        libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x00002aaaadbf1000)
        libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00002aaaaddf9000)
        libresolv.so.2 => /lib64/libresolv.so.2 (0x00002aaaadffb000)
        libnsl.so.1 => /lib64/libnsl.so.1 (0x00002aaaae211000)
$ rpm -q libjpeg
libjpeg-6b-39.fc8
libjpeg-6b-39.fc8

ellson@bock:~> ldd /usr/lib/cups/filter/imagetops
        linux-vdso.so.1 =>  (0x00007fffafdfe000)
        libcupsimage.so.2 => /usr/lib64/libcupsimage.so.2 (0x00002aaaaaed0000)
        libcups.so.2 => /usr/lib64/libcups.so.2 (0x00002aaaab0e7000)
        libgnutls.so.13 => /usr/lib64/libgnutls.so.13 (0x00002aaaab31e000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00002aaaab5a1000)
        libm.so.6 => /lib64/libm.so.6 (0x00002aaaab7bc000)
        libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00002aaaaba3f000)
        libaudit.so.0 => /lib64/libaudit.so.0 (0x00002aaaabc78000)
        libselinux.so.1 => /lib64/libselinux.so.1 (0x00002aaaabe8d000)
        libc.so.6 => /lib64/libc.so.6 (0x00002aaaac0a8000)
        libtiff.so.3 => /usr/lib64/libtiff.so.3 (0x00002aaaac400000)
        libpng12.so.0 => /usr/lib64/libpng12.so.0 (0x00002aaaac659000)
        libjpeg.so.62 => /usr/lib64/libjpeg.so.62 (0x00002aaaac87d000)
        libz.so.1 => /lib64/libz.so.1 (0x00002aaaaca9f000)
        libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x00002aaaaccb3000)
        libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x00002aaaacee1000)
        libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x00002aaaad174000)
        libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00002aaaad399000)
        libgcrypt.so.11 => /lib64/libgcrypt.so.11 (0x00002aaaad59b000)
        libgpg-error.so.0 => /lib64/libgpg-error.so.0 (0x00002aaaad7e9000)
        /lib64/ld-linux-x86-64.so.2 (0x00002aaaaacb4000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00002aaaad9ec000)
        libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x00002aaaadbf1000)
        libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00002aaaaddf9000)
        libresolv.so.2 => /lib64/libresolv.so.2 (0x00002aaaadffb000)
        libnsl.so.1 => /lib64/libnsl.so.1 (0x00002aaaae211000)
ellson@bock:~> rpm -q libjpeg
libjpeg-6b-39.fc8.x86_64
libjpeg-6b-39.fc8.i386

Is it related to the gcc issue?    Is your fc8 system totally vanilla?  I get
the same problem, consistently on 4 fc8 systems that I've tried, so I don't
understand how it can be working for you?   Is your gcc upgraded beyond fc8?  
Did you build your own cups or libjpeg rpms?

OK, the fix went into filter/image-jpeg.c, in libcupsimage.so, which is linked
from /usr/lib/cups/filter/imagetops

libcupsimage.so comes from cups-libs, which is 1.3.6-2 on my system.   I need
cups-libs-1.3.6-3 which has not been distributed.

Perhaps you made it available earlier in updates-testing, but the instructions
in #12 didn't grab cups-libs in addition to cups.   cups*1.3.6-3 seems to have
gone now.

Ah, I should have spotted that from comment #22, sorry.  I'll fix the main
package to require an exact match for the libs package, and in future updating
just 'cups' will pull in the correct libs packages.

cups-1.3.6-4.fc8 has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.