Bug 681071

I can now confirm the fix in gs trunk. I built gs from trunk, and replaced my "gs" binary, now images are not printed inverted anymore.

We do not have a printer which uses the splix driver
so that I cannot reproduce it.

For my HP LaserJet 1220 all available drivers work:
- PostScript
- ljet4 (traditional built-in Ghostscript driver)
- HPIJS (IJS driver from HPLIP for Ghostscript)
- HPCUPS (native CUPS driver from HPLIP for Ghostscript)
- Gutenprint (native CUPS driver from Gutenprint for Ghostscript)
In particular HPCUPS and Gutenprint use the Ghostscript driver "cups".

Therefore I need more information to better understand what
exactly is wrong.

Are only embedded images printed color-inverted
or is also e.g. plain text printed color-inverted like:

echo Hello | lp -d <queue>

or plain PostScript via

echo Hello | a2ps -1 -o- | lp -d <queue>

or are e.g. only image files printed color-inverted like

lp -d <queue> -o fitplot /usr/share/cups/webcontent/images/color-wheel.png

or

lp -d <queue> -o fitplot /usr/share/cups/webcontent/images/smiley.jpg


Perhaps you could attach a scan of such a color-inverted printout?

Or could you at least attach one of your documents which
print color-inverted?

Also printing PDF's with embedded images like
http://www.andy-roberts.net/misc/latex/tutorial5/import.pdf
as described in
http://bugs.ghostscript.com/show_bug.cgi?id=691759
works o.k for me.

only embedded images are printed color-inverted, text is printed correctly. 

only if I activate "force rastering" in the okular-print-dialog for my pdf document, the hole document is color-inverted.

I cannot reproduce it.

When I download
http://www.andy-roberts.net/misc/latex/tutorial5/import.pdf
and print it from okular with "force rastering" activated
in okular's print dialog "Options -> PDF Options"
I get correct colors
- when I print from okular into a PDF file
- when I print from okular into a PostScript file
- in the /var/spol/cups/d<job>-001 file when I print
  from okular into a disabled queue
- in the PostScript output of a queue for a PostScript printer

Also when I do
  ps2pdf import.pdf import.ps
the colors are correct in my import.ps, compare
http://bugs.ghostscript.com/show_bug.cgi?id=691759#c1

I don't know what "force rastering" in the okular-print-dialog
for PDFs does - perhaps the bug is there - i.e. that
okular's "force rastering" is somehow buggy and results
inverted colors?

As long as I cannot reproduce it I can do nothing here.
We won't do a partial version upgrade for Ghostscript
to an arbitrary unstable "trunk" state.
We would first of all try to find the exact bug and
then try to fix this particular bug and finally we could
provide a bugfix update package for Ghostscript.

I close the issue for now as "worksforme".
I re-open it when I can reproduce it.

I would appreciate it if you could add nevertheless
more information which might help me to reproduce it.

A blind guess:

Does it perhaps help when you add in /etc/cups/cupsd.conf a line like
  RIPCache 128m
or even
  RIPCache 1024m
(the latter only if you have at least 2GB main memory in your computer)
and afterwards restart the cupsd, see
"Various printout failures with CUPS default RIPCache 8m" at
http://en.opensuse.org/Portal:Printing

This is only a blind guess but I in the past I noticed
several very strange weird effects related to the
changed Ghostscript internal banding API...

I have not enough technical knowledge to find the exact reason/patch for the fix. but I have tested, that the splix driver prints images inverted with gs-9.0 und works fine with gs-executable replaced with the one compiled from trunk. I don't know if these bugs and these methods you tested are valid. I only noticed, that some people from http://bugs.ghostscript.com/show_bug.cgi?id=691759 
and also in this forum https://bbs.archlinux.org/viewtopic.php?pid=850972 had the same problem, also with splix driver.

I saw, that ghostscript-9.01 was released before 2 days. Since this is a stable version, that should fix my problem (is svn revision 12305, above bug was fixed 12010), could you update to that version please?

Many thanks for the information!
I will have a look...

H. Hansen,
I still like to know whether or not it is related to
the changed Ghostscript internal banding API:
Does it work when you add in /etc/cups/cupsd.conf the line
  RIPCache 128m
or even
  RIPCache 1024m
(the latter only if you have at least 2GB main memory in your computer)
and afterwards restart the cupsd?

I have the same problem. I recently upgraded to openSUSE 11.4 (from 11.3) and now I have trouble printing. I have an Samsung ML-1610 grayscale laser printer, using the driver Splix 2.0.0. When I print images, all colors are inverted, meaning black is white and vice versa. On 11.3 this wasn't an issue.

I tried to increase the RIPCache to 128m but this didn't do the trick.

Help is really appreciated. Thanks!

-Björn

I reopened this, since this seems to be a problem, which affects more people.

See e.g. https://bbs.archlinux.org/viewtopic.php?pid=850972

I know it's Arch Linux, but the problem is the same.

The problem also occurs with hplip (3.11.3a) on a HP Officejet 7550a. 

I remember trying ghostscript 9.00 from the [Printing_ghostscript] repo under openSUSE 11.3 with the same effects. Therefore I think this error is ghostscript related. 

The newer version in [home_jsmeix_branches_Printing_ghostscript] (9.01) seems to be missing the cups device, thus I was not able to test it with my setup

Although I'm very much in favor of thinking before printing, some things have to be printed and therefore I really would appreciate a quick solution.

Thanks.

Apparently this is really ghostscript-related. There is a bug ticket in ghostscripts bug tracker, describing exactly the problem.

http://bugs.ghostscript.com/show_bug.cgi?id=691759

This problem has been resolved with revision 12005.

I would really like to see an update to ghostscript in the official openSuse 11.4 repos.

Thank you!
Björn

As far as I see, this is the exact matching upstream bug report:
http://bugs.ghostscript.com/show_bug.cgi?id=691760

For now the openSUSE project "home:jsmeix:branches:Printing:ghostscript"
contains Ghostscript with a patch which should fix the issue.

ghostscript-* and libgimpprint packages for openSUSE 11.4
for 32 bit i586 and 64 bit x86_64 architecture can be downloaded from

http://download.opensuse.org/repositories/home:/jsmeix:/branches:/Printing:/ghostscript/openSUSE_11.4/

Do not use "Factory" unless you know exactly what you do.
Use the matching packages for your particular system.

The packages are
 * only for testing
 * without any guarantee or warranty
 * without any support 

As an extreme example, this means that if your complete computer
center crashes because of these packages, it is only your problem.
On the other hand this does not mean that those packages are known
to be terrible broken but they are not thoroughly tested so that
any unexpected issue can happen.

I did only a quick test on my openSUSE 11.4 x84_64 system
with a HP LaserJet 1020 which prints o.k.


H. Hansen,
Björn Jacobs,
Thomas Baumann,

I would appreciate it very much if you could test it and
provide feedback whether or not printing works o.k. for you.


Thomas Baumann, FYI:
for HPLIP the issue should happen only when you use the HPCUPS
driver in HPLIP because HPCUPS uses the CUPS device in Ghostscript
but not when you use the HPIJS driver in HPLIP because HPLIP does
not use the CUPS device in Ghostscript but the IJS interface in
Ghostscript for the external IJS driver /usr/bin/hpijs.
I.e. when you set up another print queue for your HP printer
using the HPIJS driver in HPLIP it should print correctly.

I just updated the ghostscript packages and made a test print with a file that before was not printed corretly. After the update, the output is correct.

So concerning me, this issue is gone.

Thank you Johannes,

Björn

Created attachment 425964 [details]
Scan of ghostscript printout

I've tested the updated ghostscript packages with only little improvement. I'm attaching a jpeg with scans for the different settings. The colors are still not ok for pdfs.

The printer test page seems ok for the color wheel, but the greyscale shows something which might be an overflow error. Please note, that for some obscure reason the cups logo is not printed with 9.00 ghostscript. 

The last part (*** Unable to open the initial device, quitting) is the result of using the hpijs driver, ... I've no idea where this comes from.

Thanks for your effort.

Thomas Baumann,
I will have a look - perhaps there are more issues here
in case of HPCUPS and HPIJS, see bug #630696 and the "FYI" part in
https://bugzilla.novell.com/show_bug.cgi?id=686195#c7
and regarding "Unable to open the initial device" see bug #688614
It seems something is currently messed up in some cases
in particular regarding printing with HPLIP.
In general PDFs are known to cause in some cases
any kind of obscure weird issues.
But I am not at all a PDF expert to be able to actually debug
issues which are related to PDFs.

H. Hansen,
see comment #16
https://bugzilla.novell.com/show_bug.cgi?id=681071#c16
Does this Ghostscript update let it work o.k. for you?

Thomas Baumann,
please file a new bug report regarding your particular issue
with the HPCUPS driver and attach your PDF which results
the bad output so that I can reproduce it.

Regarding "Unable to open the initial device" with
the HPIJS driver you may add comments to bug #688614
which could help me to find out the root cause.

From what I see for now with the PDF in attachment #423966 [details]
which I got via bug 686195 it seems the CUPS device
in Ghostscript produces good cups raster data.

I produce cups raster data manually using a command like

  cat /tmp/landscape.pdf \
  | /usr/bin/gs -dQUIET -dPARANOIDSAFER -dNOPAUSE -dBATCH \
    -dNOMEDIAATTRS -sDEVICE=cups -sstdout=%stderr \
    -sOUTPUTFILE=%stdout -c  -f -_ \
  | cat >/tmp/landscape.cups.raster

(The useful use of cat simulates what happens in the
 printing system - no "seek"-able or "stat"-able files
 but processing as data stream via pipes.)

Afterwards I run

 rasterview /tmp/landscape.cups.raster

and it looks o.k. - I have CUPS RasterView installed from
http://download.opensuse.org/repositories/home:/jsmeix/

But then the HPCUPS driver seems to fail to print it correctly
on my HP LaserJet 1020 so that from my current point of view
it seems the CUPS device in Ghostscript is fixed
but a different issue in the HPCUPS driver results
an insufficient printout.

If it is really a bug in the HPCUPS driver, we cannot fix it
because we do not have the model-specific knowledge to fix
bugs in the driver so that we could only "Report a Bug" at
http://hplipopensource.com/hplip-web/support.html

On the other hand with Ghostscript 8.70 the HPCUPS driver
results a good printout which indicates that there are
more issues in Ghostscript 9.00...

Your packages work for me, thank you.

I like to separate the HPLIP related issues (see comment #20)
and provide a Ghostscript bugfix update with the current fix.

openSUSE maintenance team,
I ask for a bugfix update of the ghostscript-library package
only for openSUSE 11.4 (it works for openSUSE 11.3).

If you like to have a look and perhaps even test it (see comment #16):
For now the openSUSE project "home:jsmeix:branches:Printing:ghostscript"
contains Ghostscript with a patch which should fix the issue.
ghostscript-* and libgimpprint packages for openSUSE 11.4
for 32 bit i586 and 64 bit x86_64 architecture can be downloaded from
http://download.opensuse.org/repositories/home:/jsmeix:/branches:/Printing:/ghostscript/openSUSE_11.4/

+1

I am using openSUSE 11.4 32 bit with HP OfficeJet Pro 8500 a910 and have the same problems. Graphics (and PDFs) are printed inverted using the hpcups driver. Using the hplip driver results in "Unable to open the initial device" error.

Unfortunately the new packages from http://download.opensuse.org/repositories/home:/jsmeix:/branches:/Printing:/ghostscript/openSUSE_11.4/ did not fix the hpcups problems. Graphics (and PDFs) are still printed with wrong colors. There has something changed with the new packages (other colors now), but it's still not fixed.

(In reply to comment #25)
Okay, just made some more tests using hp-tool and yast for creating the printers. The inverted colors problem with hp-cups driver still occurs no matter if I create the printer with yast or hp-tool. But "Unable to open the initial device" problem with hpijs disappears if the printer is created with yast. See #688614#c10.

Installing gs from http://download.opensuse.org/repositories/home:/jsmeix:/branches:/Printing:/ghostscript/openSUSE_11.4/ did not fix it for me.

The current stats "NEEDINFO maintenance@opensuse.org" must stay
until the openSUSE maintenance team decided
whether or not there will be an update package.

lets do it +1

The SWAMPID for this issue is 40618.
This issue was rated as low.
Please submit fixed packages until 2011-06-01.
Also create a patchinfo file using this link:
https://swamp.suse.de/webswamp/wf/40618

okay, update started. Be so kind and submit a patchinfo.

The fix does not work for me with my HP Officejet Pro 8500 A910, too.
It is a bit different, but still using wrong colors.

I've used hpcups (hp-officejet_pro_8500_a910.ppd 3.11.1.19), because the
hpijs variant does not work at all. It prints a page with:

**** Unable to open the initial device, quitting.

The "Unable to open the initial device" error has already been reported to HPLIP team at https://bugs.launchpad.net/hplip/+bug/773374 .
However, no ticket activity yet there.

FYI:
https://answers.launchpad.net/hplip/+question/155245
seems to be about the same issue for HPCUPS in HPLIP.


Marius Tomaschewski,
as a band-aid workaround for printing with the hpijs driver
it should work if you use the generic (unidirectional) CUPS
backend "socket" instead of the (bidirectional) "hp" backend, see
https://bugzilla.novell.com/show_bug.cgi?id=688614#c11

The drawback is that the unidirectional backend socket
only works for plain printing - for anything else
like scanning or device status information the
bidirectional "hp" backend would be needed, see
https://bugzilla.novell.com/show_bug.cgi?id=688614#c28

This is an autogenerated message for OBS integration:
This bug (681071) was mentioned in
https://build.opensuse.org/request/show/69715 11.4 / ghostscript-library

Submitted ghostscript-library to openSUSE:11.4:Update:Test
via submitrequest 69715 and submitted patchinfo
via https://swamp.suse.de/webswamp/wf/40618

For me this particular issue in now FIXED.

What is not fixed is the wrong colors in particular
with the HPCUPS driver in HPLIP.

Nevertheless it may take a while until ghostscript-library update
packages for openSUSE 11.4 really appear under openSUSE:11.4:Update.

I.e. when this bug report is set to "FIXED" it does not mean
that ghostscript-library update packages are already available.

The ghostscript-library update packages will have
this RPM changelog entry:
--------------------------------------------------------------
- gs.svn_diff-c_12005.diff fixes
  http://bugs.ghostscript.com/show_bug.cgi?id=691760
  which is the upstream bug for bnc#681071.
--------------------------------------------------------------

Unless "rpm -q --changelog ghostscript-library" does not show this entry,
you do not have those ghostscript-library update packages installed.

FYI:

Only for users who use the HPLIP software:

The newest HPLIP 3.11.5 is available for testing now, see
https://bugzilla.novell.com/show_bug.cgi?id=692905#c2

Update released.

This is an autogenerated message for OBS integration:
This bug (681071) was mentioned in
https://build.opensuse.org/request/show/85412 Factory / ghostscript-library

This is an autogenerated message for OBS integration:
This bug (681071) was mentioned in
https://build.opensuse.org/request/show/85461 Factory / ghostscript-library