Arch Linux

Forgot to mention that the other printer (Samsung), still worked fine, but it's a black&white only printer (don't know if it's important)

I can confirm this bug with gs 9.00-1, cups 1.4.4, and a networked HP LaserJet P3005. The generic PCL6 printer driver used to be able to print pdf documents. Now documents print halfway and often stop just before a page that contains a large image in the pdf. This is also an x86-64 installation of arch.

When the print job stops I get the following status message:
"/usr/lib/cups/filter/pstoraster failed"

I have a Canon MX860 printer that prints somewhat goofy (random garb on header/footer and margins of somewhat readable text) if there is more than 1 page (first page is fine). Downgrading ghostscript fixes this completely- I am also on x86-64.

I am using the hplip driver with my HP Photosmart C4795 and also have printing issues when using ghostscript-9.00-1 (x86_64.) When printing in color, the colors are altered as if the hue is shifted or color inverted. When printing a solid white image with black text, the black text is white and the white is black (drained my cartridges rapidly when troubleshooting.) After downgrading all my packages after an update, I installed one package at a time until I isolated this package. Reverting to ghostscript 8.71-3 (x86_64) solved my printing issues.

Can you find something helpful upstream?

Confirm the bug on a XEROX Phaser 6110MFP connected by network (static IP) and using SPLIX drivers. I'm looking upstream. For evince-gtk users, the actual version works (evince-gtk 2.30.3-1), you have to downgrade:
ghostscript 8.71-3
libspectre 0.2.6-1
as I commented in  FS#21502 .

Had a look upstream. There seem to be a few bug reports:

http://bugs.ghostscript.com/show_bug.cgi?id=691733
http://bugs.ghostscript.com/show_bug.cgi?id=691539
http://bugs.ghostscript.com/show_bug.cgi?id=691586

particularly the first one (in which I put a comment). No answer from the devs at present.

I'm using an Epson Stylux DX8400 with gutenprint driver. When printing a document that needs to be rotated, the fonts become distorted. The page as such is rotated correctly, images are rotated correctly, but fonts look as if they kept their height and tripled their width.
As above, downgrading to previous version of ghostscript and libspectre solves the problem.

Using a Samsung ML-2010 Monolaser with splix and cups pictures printed as negatives (.gif .png .jpg)

PDF files with evince or acrored prints fine.

So
https://bugs.archlinux.org/task/21524?opened=8334&type[0]=&sev[0]=&due[0]=&cat[0]=&status[0]=open&percent[0]=&reported[0]=

Depends too on the ghostscript update but issue is different.

@Johannes: "lp picture.jpg" works ok?

Same problem for me with a Samsung ML-2010 (Printing as negatives). But also pdfs are affected. Or for example I can't print maps from "google maps" anymore.

killajoe:~$ lp lampion.jpg
Anfrage-ID ist Samsung–159 (1 Datei(en))
Print is ok so might be not only ghostscript???

Prints from any Browser are inverted pictures text and maps... and printing from eog too...

When i do "print to file" as a PDF and open this with reader it prints inverted. PDF files from internet prints fine...

due to the fact that multiple users are affected and fix does not seem to be on the way i suggest to remove gs 9.00 and return back to 8.71

My problem is a little different than those described here, I am experiencing negative images (or even entire pages).
This bug looks more relevant: https://bugs.archlinux.org/task/21524 , but it's closed as a duplicate of this one... sooo...

I have OKI B410d printer, using OKI's own driver, available as AUR package: http://aur.archlinux.org/packages.php?ID=38047

Everything is fine with ghostscript 8.71-3, upgrading to 9.00-1 causes images in PDF files to be printed
in negative. I thought it was a problem with my .tex files or pdflatex or png files themselves.
PDF files that contain png images with transparency cause the entire page to be negative.
Without transparency just the png file is negative. JPG files are negative as well, converting between png, eps and pdf
formats doesn't help either. I even tried taking a screenshot of a png image ;)
Creating a negative png image, putting it in the .tex document and printing that results in correct printout
(the same as when original image and ghostscript 8.71 is used).

I have also tried using different drivers, for example ljet4 works fine, without
negative images, but it stops working after the first printout - all I get is some garbage on the paper.

I also tried printing a pdf file downloaded from the Internet, from this tutorial:
http://www.andy-roberts.net/misc/latex/latextutorial5.html (this file: http://www.andy-roberts.net/misc/latex/tutorial5/import.pdf )
and the images were inverted as well.

I opened a bug report for the negative images here: http://bugs.ghostscript.com/show_bug.cgi?id=691759

Everybody who is using 3rd party driver packages may try to recompile it and to reconfigure the printer. I don't know if they need to pickup some new GS api.

From the .so bump we have rebuild all packages in extra. Whoever has problems after the release should get in contact with upstream devs. So far I cannot see a packaging bug. A downgrade won't fix the bugs for the future and can only be a temporary solution.

You may also want to have a look at other distros and their related bugs:
http://pkgs.fedoraproject.org/gitweb/?p=ghostscript.git;a=blob;f=ghostscript.spec;h=00c21bb8a363149d01d9adaf61517b2f6129f229;hb=master
http://packages.debian.org/experimental/ghostscript
http://gentoo-portage.com/AJAX/Ebuild/117829/View

The upstream bug report (http://bugs.ghostscript.com/show_bug.cgi?id=691733) has been updated. Now they are ale to reproduce the bug without real printing - only by a ghostscript conversion. They also mention that some patch-prone distro has backported the bug back to 8.71. The bug is NOT present in the Arch version 8.71 of the package.

Therefore, recompiling the drivers may not help much in my view (but a try is worth thousand views!).

Andreas: The OKI driver I have doesn't have any binaries, just a ppd file and cups' filter script 'rastertookimonochrome', which is a script, not a binary.
This script, in turn, runs 'gs' from ghostscript, and 'rastertohp' which is a binary, but is a part of regular cups (and doesn't directly link against anything ghostscript-related).

I have tried the procedure to reproduce the bug without printing, and it produces correct output using Arch's ghostscript 8.71-3 package.
When when 9.00-1 is used the first page looks fine, and the rest is just garbage. It does not produce negative images though,
so it might be a completely different bug :(

Update: Using different input file (the one I used before) results in negative images... (which, I guess, still doesn't necessarily mean that this is the same bug)

With this bug I am stuck with updates (using GS 8.71-3). :-)

Hm, actually what is the policy for using the [testing] repo? I thought major version updates go through testing first,
but this one went straight to [extra]... Which is rather unfortunate... I would run into the same problem anyway
since I use [testing], but at least people who don't use it would not have problems :)

I guess this is the price for using bleeding edge. If this is what you get from [extra], imagine what you'll get from [testing]! Something nasty!

I am using [testing]. It's not nasty, in most cases it's just fine.

Ghostscript 9.0 has been in testing from 8th Oct. - 19th Oct. without one bug reported. This happens quiet often when we are on the bleading edge. But not so many people seem affected that it's worth a general downgrade.

Whener you find a good solution drop me a line. Usually Fedora is doing heavy patching to stay near the upstream developement. Look out for similar bugs they may have and contact the upstream devs.

Build of SVN-entry failed may that helps.

Please test gs 9.00-2 from testing.

I tested the pkg from testing, and it continues to print images with inverted colors.

The pkg in testing -2 fix addresses other issues. I've cc'ed the above mentioned upstream reports. Please help there to solve them.

With 9.00-2 the problem for me is partially solved: now the pages are correctly printed but, from the second page on, the margins are filled with vertical black lines.
I have an HP B-109.

The problem is not solved for me:

XEROX Phaser 6110 MFP
Splix 2.0.0-7

For the garbled output (after the first page) issue, see my comment and patch on http://bugs.ghostscript.com/show_bug.cgi?id=691733#c22.

It doesn't solve the inverted images issue though.

The patch works for me, limited to the second-page garbage output though. Thanks a lot foutrelis.

No idea about inverted colors. I expect it to be an unrelated bug.

Looks like my patch was wrong and caused a regression, triggering an older bug. An alternate solution has been committed in r12007 upstream. The person that committed it has asked for it to be tested for any regressions.

Also, the issue with the inverted colors was finally fixed in r12005. :D

Garbles output seems to be solved by a correct patch in SVN rev 12010 (see upstream bug report). foutrelis and Till Kamppeter have the merit :-)

This makes me think that all bugs reported here have been solved. We only need to make archlinux adopt the patchset. We either wait for a new upstream release, or include the corrections of r12005 and r12010 into the current package.

I also had the problem "pstoraster failed" whenever I tried to print (I'm using CUPS+hplip). This is fixed after building from svn.

This seems to be related to  FS#21524  merged here. From the list, I understand
that an upstream fix in ghostscript may have solved this problem, but I wanted
to make sure this information was captured here in case the issue I see with
HP drivers is somehow different from the Samsung/Epson issue. The problem with
inverse greyscale I see is as follows:

Saving a google maps map as pdf (in firefox) and then printing in Okular using a HP
Laserjet 4 via the HP Laserjet PCL 4/5 driver prints the maps in inverse greyscale
(i.e. the whole page is black with the roads shown in white). I've checked the
driver settings and regardless of whether you specify greyscale or color, the
inverse printing is the same. Prints fine from windows.

I've added an upstream patch for http://bugs.ghostscript.com/show_bug.cgi?id=691733. Can you please confirm that at least this part of the issue is now solved?

For the other bugs please open new issues that we can try to fix.

My issue is not resolved. I still get negative images...

What should I do?
Reopen  FS#21524 ?

Your issue seems to be http://bugs.ghostscript.com/show_bug.cgi?id=691759 - can you try out the suggested commit: http://ghostscript.com/pipermail/gs-commits/2011-January/012113.html ?

Patching the ghostscript with rev 12005 patch seems to solve my problem as well :)

patch applied. anything left from the issues reported here?

Please see comments from foutrelis and me above. The right SVNs seem to be 12005,12007, and 12010. Please include those three and we should solve most of the problems.

r12010 is just a typo fix. r12007 is already included in the last fix I've applied (patch from Fedora has it included) - closing this issue now. for new bugs please open new reports.