HPLIP

acrobat reader 9.3 prints rgb://a0:00:3c (redish color) as rgb://a0:ff:3c (greenish color)

Bug #534096 reported by Nicholas Vinson
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
HPLIP
New
Undecided
Unassigned
Gentoo Linux
Fix Released
Medium

Bug Description

Long story short, I have a bank statement that uses the color a0:00:3c, and
when I print it using acroread 9.3 the color printed is a0:ff:3c. Acroread
renders it on the screen correctly. I've repeated the test using GIMP, evince,
and xPDF and none show the same error. I've also tested acroread 9.3 on
Xubuntu 9.10 and did see the error.

Reproducible: Always

Steps to Reproduce:
1.load test.pdf (attached) using acroread 9.3
2.tell it to print

Actual Results:
Printout has two greenish circles. This has been tested on both Gentoo and Xubuntu. The problem exists on both systems. Details for the Gentoo system are attached.

Expected Results:
The left circle on the printout should have been a redish possibly maroon color (I'm not sure on the name, but it should look reasonably close to what is displayed on the screen.)

Printer is an HP Officejet J6480.

HPLIP driver: 3.10.2
CUPS Version: 1.4.2-r1 (Xubuntu 1.4.1)

The bug at http://bugs.gentoo.org/show_bug.cgi?id=307267 show the experimentation I conducted (as well as some initial assumptions) prior to filing this bug.

See original description
Revision history for this message
Nicholas Vinson (nvinson) wrote :
Revision history for this message
Nicholas Vinson (nvinson) wrote :
Revision history for this message
Nicholas Vinson (nvinson) wrote :
description: updated
description: updated
Revision history for this message
Naga Samrat Chowdary, Narla (samrat-hplip) wrote :

Printing from applications (Acrobat reader/Evince Reader/GIMP) means, application form "lp" command and send to shell for printing.
In Acrobar reader case, it may forming different "lp" command while submitting to shell.
If it is problem with hplip-3.10.2 then all application should print like the same.

you can see how the appication forming the "lp" command in acrobat, by using print properties.

please do the following from both acrobar and GIMP, attach the log messages
1. empty the file /var/log/cups/messages
2. vi /etc/cups/cupsd.conf and set

LogLevel warn
to
LogLevel debug

3. restart cups (/etc/init.d/cups restart)
4. fire a print
5. attach the error_log messages (/var/log/cups/error_log)

Thank you for reporting with HPLIP.
Naga Samrat Chowdary, Narla.

Revision history for this message
Nicholas Vinson (nvinson) wrote :

As requested I am attaching the error logs from the prints done by GIMP and Acrobat reader 9.3.

I am also attaching the error log from a xpdf print (prints correctly from xpdf as well).

Revision history for this message
Nicholas Vinson (nvinson) wrote :
Revision history for this message
Nicholas Vinson (nvinson) wrote :
Revision history for this message
In , Pacho-gentoo (pacho-gentoo) wrote :
Download full text (4.6 KiB)

This problem disappeared some time ago when I started to use "Let printer determine colors" acroread advanced option. But, sadly, from some days (I am unable to know what update broke this) it fails even with that option. The same occurs when I manually try to print it using "lpr test.pdf", while other tools not using "lpr" work ok

What info do you need for trying to find the problem here?
app-text/ghostscript-gpl-8.71-r4 (the same with -r2, -r3, 8.70...)
net-print/cups-1.3.11-r2
net-print/hplip-3.10.2-r4 (the same with 3.9.12-r1)

My emerge --info:
Portage 2.1.8.3 (default/linux/amd64/10.0/desktop/gnome, gcc-4.3.4, glibc-2.10.1-r1, 2.6.32-gentoo-r7 x86_64)
=================================================================
System uname: Linux-2.6.32-gentoo-r7-x86_64-AMD_Athlon-tm-_64_Processor_3200+-with-gentoo-1.12.13
Timestamp of tree: Sun, 02 May 2010 15:00:01 +0000
ccache version 2.4 [enabled]
app-shells/bash: 4.0_p37
dev-java/java-config: 2.1.10
dev-lang/python: 2.6.4-r1
dev-util/ccache: 2.4-r7
dev-util/cmake: 2.6.4-r3
sys-apps/baselayout: 1.12.13
sys-apps/sandbox: 1.6-r2
sys-devel/autoconf: 2.13, 2.63-r1
sys-devel/automake: 1.9.6-r3, 1.10.3, 1.11.1
sys-devel/binutils: 2.18-r3
sys-devel/gcc: 4.3.4
sys-devel/gcc-config: 1.4.1
sys-devel/libtool: 2.2.6b
virtual/os-headers: 2.6.30-r1
ACCEPT_KEYWORDS="amd64"
ACCEPT_LICENSE="*"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=native -O2 -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/X11/xkb /usr/share/config /var/lib/hsqldb"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c"
CXXFLAGS="-march=native -O2 -pipe"
DISTDIR="/usr/distfiles"
FEATURES="assume-digests autoaddcvs ccache cvs distlocks fixpackages multilib-strict news parallel-fetch protect-owned sandbox sfperms sign split-log strict test unmerge-logs unmerge-orphans userfetch"
GENTOO_MIRRORS="ftp://ftp.free.fr/mirrors/ftp.gentoo.org"
LANG="es_ES.UTF-8"
LDFLAGS="-Wl,-O1"
LINGUAS="es es_ES en_US"
MAKEOPTS="-j2"
PKGDIR="/usr/local/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/portage/local/layman/sunrise /usr/portage/local/layman/suka /usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="3dnow 3dnowext X a52 aac acl acpi alsa amd64 applet avahi bash-completion berkdb branding bzip2 cairo cddb cdinstall cdr cleartype cli consolekit cracklib crypt css cups cxx daap dbus djvu dri dts dvd dvdr dvi eds emboss encode evo exif fam fat ffmpeg firefox flac fortran fuse gdbm gdu gif glitz gnome gnome-keyring gpm gstreamer gtk hal iconv imagemagick java jpeg kdehiddenvisibility kpathsea latex lcms libnotify lyx lzma mad mikmod mmx mmxext mng modules mono mp3 mp4 mpeg mudflap multilib musicbrainz nautilus ncurses network network-cron nls nptl np...

Read more...

Revision history for this message
In , Pacho-gentoo (pacho-gentoo) wrote :

Created attachment 230073
test.pdf

Revision history for this message
In , Pacho-gentoo (pacho-gentoo) wrote :

It's a hplip problem (all versions in tree are affected by this) when using "hpcups" filter instead of "hpijs" one

Revision history for this message
In , Pacho-gentoo (pacho-gentoo) wrote :

Created attachment 230193
PSC_1600.ppd -> hpcups (and failing one)

Revision history for this message
In , Pacho-gentoo (pacho-gentoo) wrote :

Created attachment 230195
PSC_1600_2.ppd -> hpijs (and working one)

Revision history for this message
In , Billie-gentoo (billie-gentoo) wrote :

Created attachment 230211
Test series with different printer drivers, files and programs

I can reproduce this bug here. This looks similar to bug #307267. The user who reported this bug already opened an hplip bug as he verified this problem with Xubuntu. So this does not look like a Gentoo specific bug.

I did a test series with your test file and the one from bug #307267. Like you said this only happens with hpcups, but the results with for the two test files are different like you see in the attached file.

Revision history for this message
Daniel Pielmeier (daniel-pielmeier) wrote :

There is also a similar bug #318183 [1] in Gentoo with a different test file which leads to different results. First I also thought this is not a bug in hplip but in lpr or the applications forming an incorrect lpr command.

However when looking at the attached file you see this only occurs if the hpcups driver is in use, the hpijs driver does not have this problem. Also interesting is that acrobat is using a different lpr command depending on whether hpis or hpcups is in use.

In the attached file I show the results of using different drivers with the two test files from the Gentoo bugs and with different programs. test-307267.pdf is the attached test file from Gentoo bug #307267 [2] and test-318183.pdf is from Gentoo bug #318183 [1] .

[1] http://bugs.gentoo.org/318183
[2] http://bugs.gentoo.org/307267

Revision history for this message
In , Pacho-gentoo (pacho-gentoo) wrote :

Thanks a lot for the info. I will CC to https://bugs.launchpad.net/hplip/+bug/534096

Is there any more that I could do for helping on this? Or should I wait for https://bugs.launchpad.net/hplip/+bug/534096 to be solved at first?

Thanks :-)

Revision history for this message
Pacho Ramos (pacho) wrote :

I am also affected by a similar problem:
http://bugs.gentoo.org/show_bug.cgi?id=318183

Revision history for this message
In , Billie-gentoo (billie-gentoo) wrote :

(In reply to comment #6)
> Is there any more that I could do for helping on this? Or should I wait for
> https://bugs.launchpad.net/hplip/+bug/534096 to be solved at first?

Your welcome. Can you please add the use flags you have enabled for for hplip. Nowadays there is also "emerge --info package-atom" just in case you did not know.

I don't think there is anything we can do until upstream provides a patch besides using the hpijs driver.

Revision history for this message
In , Pacho-gentoo (pacho-gentoo) wrote :

(In reply to comment #7)
> Your welcome. Can you please add the use flags you have enabled for for hplip.
> Nowadays there is also "emerge --info package-atom" just in case you did not
> know.
>

Of course ;-)
net-print/hplip-3.9.12-r1 was built with the following:
USE="X hpcups hpijs libnotify (multilib) policykit qt4 scanner test -doc -fax -minimal -new-hpcups -parport -snmp -static-ppds -udev-acl"

As you can see, I have both enabled (hpijs and hpcups) and, then, when I configure cups, I am able to choose between two provided ppds.

I have also tried to enable "new-hpcups"... but I wasn't able to find any ppd for my printer with it :-(

> I don't think there is anything we can do until upstream provides a patch
> besides using the hpijs driver.
>

OK but, why ebuild defaults to +hpcups? Is it preferred by upstream?

Revision history for this message
In , Billie-gentoo (billie-gentoo) wrote :

(In reply to comment #8)
> I have also tried to enable "new-hpcups"... but I wasn't able to find any ppd
> for my printer with it :-(

I have re-checked the new-hpcups flag, looks like it does not do anything nowadays. I will remove it from the ebuild.

> OK but, why ebuild defaults to +hpcups? Is it preferred by upstream?

Yes, take a look at the release notes for 3.9.6 at http://hplipopensource.com/hplip-web/release_notes.html

Bug Watch Updater (bug-watch-updater)
Changed in gentoo:
status: Unknown → Confirmed
Bug Watch Updater (bug-watch-updater)
Changed in gentoo:
importance: Unknown → Medium
Revision history for this message
In , Pacho-gentoo (pacho-gentoo) wrote :

With a different printer (a Deskjet 2050 j510), I have seen hpcups driver causes black cartridge to not be used for printing black texts, causing them to be seen as "grey". Hpijs driver also fixes this, maybe ebuild should also build +hpijs by default, that way most people could easily choose between both alternatives and check for the best one for them

Bug Watch Updater (bug-watch-updater)
Changed in gentoo:
status: Confirmed → Unknown
Revision history for this message
In , Billie-gentoo (billie-gentoo) wrote :

Still a problem with hplip-3.12.2?

Revision history for this message
In , Pacho-gentoo (pacho-gentoo) wrote :

The printer affected by this driver issue died time ago and, then, I cannot test :(

Revision history for this message
In , Billie-gentoo (billie-gentoo) wrote :

I am able to print the attached test page with lpr, acroread, qpdfview and gimp with correct colors. Closing

Bug Watch Updater (bug-watch-updater)
Changed in gentoo:
status: Unknown → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.