Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 166460 - image displays in eog, but prints mostly grey
Summary: image displays in eog, but prints mostly grey
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: cups
Version: 8
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Tim Waugh
QA Contact:
URL:
Whiteboard:
: 166461 (view as bug list)
Depends On:
Blocks: F9Target
TreeView+ depends on / blocked
 
Reported: 2005-08-21 23:29 UTC by John Ellson
Modified: 2008-04-09 05:11 UTC (History)
1 user (show)

Fixed In Version: 1.3.6-4.fc8
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-04-09 05:11:55 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
logo, possibly generated with Adobe Photoshop 7.0 (deleted)
2005-08-21 23:29 UTC, John Ellson
no flags Details
/etc/cups/ppd/Officejet_Pro_K550.ppd (deleted)
2008-02-27 23:29 UTC, John Ellson
no flags Details
output of /usr/lib/cups/filter/imagetops filter (deleted)
2008-02-28 10:00 UTC, Tim Waugh
no flags Details
imagetops.ps (deleted)
2008-04-01 16:35 UTC, Tim Waugh
no flags Details
image produced locally by imagetops filter (deleted)
2008-04-02 04:22 UTC, John Ellson
no flags Details
filter-through-imageps.tar.gz (deleted)
2008-04-02 12:28 UTC, Tim Waugh
no flags Details


Links
System ID Private Priority Status Summary Last Updated
CUPS Bugs and Features 2727 0 None None None Never

Description John Ellson 2005-08-21 23:29:05 UTC
Description of problem:
The attached image fails to print correctly.  Colors all wrong.
Prints OK after convertion to .png using gimp.

Image looks OK in eog and gimp.

Version-Release number of selected component (if applicable):
desktop-printing-0.19-2

How reproducible:
100%

Steps to Reproduce:
1.lpr sickles_4c_logo.jpg
2.
3.
  
Actual results:


Expected results:
Ability to print jpg images


Additional info:

Comment 1 John Ellson 2005-08-21 23:29:06 UTC
Created attachment 117957 [details]
logo, possibly generated with Adobe Photoshop 7.0

Comment 2 Matthias Clasen 2005-10-03 04:33:52 UTC
*** Bug 166461 has been marked as a duplicate of this bug. ***

Comment 3 Tim Waugh 2008-02-27 11:53:35 UTC
Are you still seeing this problem?

Comment 4 John Ellson 2008-02-27 14:07:33 UTC
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

Comment 5 Tim Waugh 2008-02-27 14:46:14 UTC
Please attach the PPD file you are using (/etc/cups/ppd/<queuename>.ppd).

Comment 6 John Ellson 2008-02-27 23:29:05 UTC
Created attachment 296141 [details]
/etc/cups/ppd/Officejet_Pro_K550.ppd

Comment 7 Tim Waugh 2008-02-28 10:00:42 UTC
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.

Comment 8 Tim Waugh 2008-02-28 10:01:12 UTC
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...


Comment 9 Tim Waugh 2008-02-28 10:19:05 UTC
Reported upstream.

Comment 10 Tim Waugh 2008-02-28 22:36:46 UTC
Fix has been committed upstream and will be in 1.3.7.

Comment 11 Fedora Update System 2008-02-28 22:52:05 UTC
cups-1.3.6-3.fc8 has been submitted as an update for Fedora 8

Comment 12 Fedora Update System 2008-03-01 09:25:58 UTC
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

Comment 13 John Ellson 2008-03-25 21:54:11 UTC
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 ?

Comment 14 Tim Waugh 2008-03-26 08:05:27 UTC
No, it's because the back-ported fix doesn't work for some reason.  OK, thanks
for testing.

Comment 15 Tim Waugh 2008-03-31 16:14:23 UTC
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.

Comment 16 John Ellson 2008-04-01 16:10:22 UTC
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?


Comment 17 Tim Waugh 2008-04-01 16:35:47 UTC
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.

Comment 18 Tim Waugh 2008-04-01 16:37:47 UTC
(You will shortly see a comment here from Fedora Update System about an updated
package -- please ignore that comment.)

Comment 19 John Ellson 2008-04-02 04:22:46 UTC
Created attachment 300009 [details]
image produced locally by imagetops filter

Comment 20 John Ellson 2008-04-02 04:24:46 UTC
Your version of imagetops from #17 printed ok, using: lpr imagetops.ps

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

Comment 21 Tim Waugh 2008-04-02 10:17:17 UTC
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 


Comment 22 John Ellson 2008-04-02 12:08:06 UTC
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


Comment 23 Tim Waugh 2008-04-02 12:28:24 UTC
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?

Comment 24 John Ellson 2008-04-02 12:49:56 UTC
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

Comment 25 John Ellson 2008-04-02 14:51:01 UTC
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?


Comment 26 Tim Waugh 2008-04-02 15:10:03 UTC
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


Comment 27 John Ellson 2008-04-02 18:32:56 UTC
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


Comment 28 John Ellson 2008-04-02 18:42:56 UTC
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?




Comment 29 John Ellson 2008-04-02 20:25:24 UTC
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.

Comment 30 Tim Waugh 2008-04-03 08:16:02 UTC
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.

Comment 31 Fedora Update System 2008-04-09 05:11:50 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.