Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#21388 - [ghostscript] Upgrade to v9 breaks printing of ps/pdf documents on Epson printer

Attached to Project: Arch Linux
Opened by Massimiliano Torromeo (mtorromeo) - Thursday, 21 October 2010, 13:41 GMT
Last edited by Andreas Radke (AndyRTR) - Monday, 24 January 2011, 15:06 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Andreas Radke (AndyRTR)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 22
Private No

Details

Description:
I have 2 printers (Samsung and Epson). Both were configured and worked correctly.
After the last upgrade of ghostscript (ghostscript-9.00-1-x86_64), the Epson printer doesn't print anymore pdf documents. Printing an html page from chromium still works.
The printer is using the following driver: Epson AcuLaser C1900PS Foomatic/eplaser.
If I change the driver to "Epson AcuLaser C1900PS Foomatic/ljet4" which is compatible but only black&white, printing the pdf documents works.
Downgrading to ghostscript-8.71-3-x86_64 fixes the problem.
No errors are displayed in any of the cups log files.
The problem has been reproduced on 5 different machines.

Additional info:
* broken: ghostscript-9.00-1
* working: ghostscript-8.71-3
* arch: x86_64

Steps to reproduce:
* Install ghostscript-9.00-1
* Configure an "Epson AcuLaser C1900PS Foomatic/eplaser" printer
* Print a PDF from any pdf viewer (okular, epdfview)

Expected result:
* The printer outputs the document.

Actual result:
* The printer doesn't respond and shows no sign of activity.
This task depends upon

Closed by  Andreas Radke (AndyRTR)
Monday, 24 January 2011, 15:06 GMT
Reason for closing:  Fixed
Comment by Massimiliano Torromeo (mtorromeo) - Thursday, 21 October 2010, 13:44 GMT
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)
Comment by voltaic (voltaic) - Saturday, 23 October 2010, 21:54 GMT
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"
Comment by Jeremy M. (jskier) - Saturday, 23 October 2010, 22:50 GMT
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.
Comment by Plex (plexor) - Monday, 25 October 2010, 20:31 GMT
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.
Comment by Andreas Radke (AndyRTR) - Tuesday, 26 October 2010, 17:10 GMT
Can you find something helpful upstream?
Comment by Fabio Zanini (iosonofabio) - Thursday, 28 October 2010, 12:40 GMT
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 .
Comment by Fabio Zanini (iosonofabio) - Thursday, 28 October 2010, 13:14 GMT
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.

Comment by Andreas Tiemeyer (grey) - Thursday, 28 October 2010, 23:37 GMT
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.
Comment by Johannes Kamprad (killajoe) - Friday, 29 October 2010, 20:23 GMT
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.


Comment by Gerardo Exequiel Pozzi (djgera) - Friday, 29 October 2010, 20:42 GMT
@Johannes: "lp picture.jpg" works ok?
Comment by Christian (saedelaere) - Saturday, 30 October 2010, 07:43 GMT
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.
Comment by Johannes Kamprad (killajoe) - Saturday, 30 October 2010, 08:52 GMT
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...
Comment by Johannes Kamprad (killajoe) - Tuesday, 02 November 2010, 19:09 GMT
When i do "print to file" as a PDF and open this with reader it prints inverted. PDF files from internet prints fine...
Comment by Plex (plexor) - Friday, 05 November 2010, 23:42 GMT
Comment by jozef riha (jose1711) - Saturday, 06 November 2010, 06:54 GMT
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
Comment by Jakub Schmidtke (sjakub) - Tuesday, 09 November 2010, 05:23 GMT
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
Comment by Andreas Radke (AndyRTR) - Tuesday, 09 November 2010, 16:21 GMT
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
Comment by Fabio Zanini (iosonofabio) - Tuesday, 09 November 2010, 20:16 GMT
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!).
Comment by Jakub Schmidtke (sjakub) - Wednesday, 10 November 2010, 01:11 GMT
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).
Comment by Jakub Schmidtke (sjakub) - Wednesday, 10 November 2010, 01:37 GMT
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)
Comment by Alex (Alex Arch User) - Saturday, 20 November 2010, 18:08 GMT
With this bug I am stuck with updates (using GS 8.71-3). :-)
Comment by Jakub Schmidtke (sjakub) - Sunday, 21 November 2010, 05:51 GMT
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 :)
Comment by Alex (Alex Arch User) - Sunday, 21 November 2010, 09:55 GMT
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!
Comment by Jakub Schmidtke (sjakub) - Sunday, 21 November 2010, 10:01 GMT
I am using [testing]. It's not nasty, in most cases it's just fine.
Comment by Andreas Radke (AndyRTR) - Sunday, 21 November 2010, 11:28 GMT
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.
Comment by Johannes Kamprad (killajoe) - Thursday, 02 December 2010, 09:12 GMT
Build of SVN-entry failed may that helps.



Comment by Andreas Radke (AndyRTR) - Saturday, 18 December 2010, 10:50 GMT
Please test gs 9.00-2 from testing.
Comment by Günter Loch (gnloch) - Saturday, 18 December 2010, 11:27 GMT
I tested the pkg from testing, and it continues to print images with inverted colors.
Comment by Andreas Radke (AndyRTR) - Saturday, 18 December 2010, 13:05 GMT
The pkg in testing -2 fix addresses other issues. I've cc'ed the above mentioned upstream reports. Please help there to solve them.
Comment by Luca Zanetti (howl) - Saturday, 18 December 2010, 15:46 GMT
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.
Comment by Fabio Zanini (iosonofabio) - Sunday, 19 December 2010, 11:38 GMT
The problem is not solved for me:

XEROX Phaser 6110 MFP
Splix 2.0.0-7
Comment by Evangelos Foutras (foutrelis) - Friday, 07 January 2011, 09:53 GMT
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.
Comment by Fabio Zanini (iosonofabio) - Friday, 07 January 2011, 10:09 GMT
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.
Comment by Evangelos Foutras (foutrelis) - Saturday, 08 January 2011, 06:44 GMT
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
Comment by Fabio Zanini (iosonofabio) - Saturday, 08 January 2011, 13:07 GMT
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.
Comment by Bruce V Chiarelli (bccomm) - Monday, 17 January 2011, 07:47 GMT
I also had the problem "pstoraster failed" whenever I tried to print (I'm using CUPS+hplip). This is fixed after building from svn.
Comment by David C. Rankin (drankinatty) - Tuesday, 18 January 2011, 15:35 GMT

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.
Comment by Andreas Radke (AndyRTR) - Saturday, 22 January 2011, 21:39 GMT
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.
Comment by Jakub Schmidtke (sjakub) - Saturday, 22 January 2011, 23:05 GMT
My issue is not resolved. I still get negative images...

What should I do?
Reopen  FS#21524 ?
Comment by Andreas Radke (AndyRTR) - Saturday, 22 January 2011, 23:14 GMT Comment by Jakub Schmidtke (sjakub) - Sunday, 23 January 2011, 00:11 GMT
Patching the ghostscript with rev 12005 patch seems to solve my problem as well :)
Comment by Andreas Radke (AndyRTR) - Sunday, 23 January 2011, 09:54 GMT
patch applied. anything left from the issues reported here?
Comment by Fabio Zanini (iosonofabio) - Monday, 24 January 2011, 10:41 GMT
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.
Comment by Andreas Radke (AndyRTR) - Monday, 24 January 2011, 15:01 GMT
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.

Loading...