slow photo printing since upgrading Feisty to Gutsy

Please do the following test:

- Edit /etc/cups/cupsd.conf adding a line "FileDevice yes"
- Restart CUPS with "sudo /etc/init.d/cupsys restart"
- Modify your print queue with "lpadmin -p <name of your print queue> -E -v file:/dev/usblp0"

Try to print again. Is it faster now?

I have tried the first 2 things you suggested above, I added the line FileDevice yes without quotes to the end of the file. however, I cannot modify my print queue as you suggest. I cannot open the file to edit it. There is a red - icon next to it and it says no known file type if I try to open it as sudo or as regular user. Also, how do I know what <name of your print queue> is?

After doing only the first 2 things, there is no change in print behavior or in what is displayed in top.

Thank you for your speedy reply

To edit /etc/cups/cupsd.conf do

sudo gedit /etc/cups/cupsd.conf

In the editor window coming up then add the line

FileDevice yes

to the end of the file. Restart CUPS with the command

sudo /etc/init.d/cupsys restart

then.

For modifying the print queue execute the command

lpstat -v

at first. You get one line for each print queue on your system. The name of the queue is the word between "device for " and the colon (":"). Replace the "<name of your print queue>" in

lpadmin -p <name of your print queue> -E -v file:/dev/usblp0

by the name of the queue for your Canon printer,

OK, thank you for the explicit instructions. I did this for the 4 instances of the i960 printer that I have defined on my system. (one for each paper size and photo paper vs. plain paper)
marty@tux:~$ lpstat -v
device for DeskJet-895C: smb://home/UPSTAIRS/HPDeskJe
device for i960_4x6_photo: usb://Canon/i960
device for i960_5x7_photo: usb://Canon/i960
device for i960_8.5x11_photo: usb://Canon/i960
device for i960_tux: usb://Canon/i960
device for PDF: cups-pdf:/
marty@tux:~$ lpadmin -p i960_4x6_photo -E -v file:/dev/usblp0
marty@tux:~$ lpadmin -p i960_5x7_photo -E -v file:/dev/usblp0
marty@tux:~$ lpadmin -p i960_8.5x11_photo -E -v file:/dev/usblp0
marty@tux:~$ lpadmin -p i960_tux -E -v file:/dev/usblp0
marty@tux:~$

It now takes about 45 seconds to get the printer going instead of 2 minutes. Under Feisty, this was no more than 10 seconds. top no longer mentions usb cpu use. gs now shoots up to 98% cpu and the resulting photos have all the colors way off, shifted heavily towards red. At least, the other way, it was slow, but the pictures looked good. These are unusable. How do I undo the lpadmin command? Do you have any other suggestions?

Thank you for your rapid response to this issue.

To undo the lpadmin command do for each print queue

lpadmin -p <name of your print queue> -E -v usb://Canon/i960

Thank you for you quick response.
I undid the lpadmin command as you suggested and after tinkering with the turboprint driver, finally got it to print again. However, the prints still looked horrible. I then tested the printer with a windows machine and discovered I had a hardware problem that coincidentally happened just as I followed your instructions above. I have since resolved the hardware issue (dirty print heads) and redid all the commands as you gave them to me above. It now stays in the que for a 4x6 for 1 min. 12 seconds, instead of 2 mins. 15 seconds. top shows gs shooting up to 99% cpu. It appears, the usb backend for cups is only part of the problem, there is still an issue with ghostscript. Under Feisty, this kind of print would stay in the que for no more than 5 seconds or so.

So are there any other thoughts on why ghostscript (gs) is using 99% of cpu resulting in slow photo printing?

There were many updates to cups today. All installed without incident. Printing, however still takes 65 seconds for a 4x6 color photoprint with gs using 99% cpu as indicated in top.

same here ghostscript is slow as a dog, especially for .ps files containing large bitmaps. The problem is definitely in gs, and not in cups, since gv is also very slow and shows gs running on 99% cpu with ps -A

I was printing some 8 1/2 x 11 color photos today and they sat in the print que for 4 mins. 30 seconds before sending to the printer. This really is not very usable for prints this large. I have not made any changes to the system since changing the lpadmin command as noted above. I still have it set to lp0.

1) Did all the cups updates take care of the cups bug?
   Should I change lpadmin back to the original way?

2) Is there any chance the ghostscript regression will be fixed?

I forgot to mention, top still says gs is using 98-99% cpu while this is happening.

Installed several updates to ghostscript today to fix encrypted pdf printing bug. They had no effect on the bug reported in this post and printing a 4x6 color photo still pauses for 65 seconds in print que with top showing gs using 99% cpu.

This bug is still open and not resolved.

Confirming this bug (or #159389) on 2.6.22-14-generic #1 SMP Tue Dec 18 08:02:57 UTC 2007 i686 GNU/Linux
Epson PictureMate takes over 15 minutes to print a single 4x6 photo. htop shows lp and gs taking all of both cores of my Athlon dual core 4200+, plus a gig of RAM, plus all my swap.

After all the updates to cups and ghostscript, I wanted to try returning the system to its original configuration and time it. So, undoing the change to cupsd.conf and resetting all the drivers back the way they were resulted in top showing 49% cpu for gs and 49% cpu for cups and having a 4x6 photo print remain in print que for 2mins. 45 seconds. Redoing the "cups patch" as above got rid of the cups cpu hit, but as before, gs spikes to 98-99% cpu and it sits in the que for 72 seconds. It is slowly getting worse. This ghostscript bug has not been resolved. Also, the cups problem remains, but at least there is a work around. As before, plain paper documents print almost instantly, it is only photo printing that is affected. Could Till Kamppeter please shed some light on whether anything is being done about these regressions? Will they be fixed in Hardy?

in Hardy is it still same :(

Since upgrading to Hardy, the cups issue is resolved. I have all the cups settings back to system defaults and there is no mention of it in top during photo printing. Unfortunately, gs still spikes to 88+% and 4x6 photo prints sit in que for 85 seconds. The ghostscript bug is still open.

Confirmed.

Testing conditions: Gwenview Printing Assistant, printing a 4 MP photo, output 15x11,5 cm (~6x4 inches)

gs took between 1 minute and 1,5 minutes. I don't know really if this is a long time but I guess it is.

This one and a half minute figure is also something I'm experiencing in Hardy. (and before in Gutsy as well)
You can multiply that time by the number of pictures you're putting on one page, regardless of their size.
For example, if you print 8 photos on a single page, it takes > 10 minutes.
3 pages with 8 photos takes > 40 minutes, etc.
For a beefy dual core with 3GB or RAM and otherwise unused, this seems to expose a serious problem in gs.

Mattcasters, I tried opening a bug at ghostscript, but after a brief go around with them, they decided it was just my system, so they closed it. If you add your experience, maybe they can figure out what's going on. Here is the link. http://bugs.ghostscript.com/show_bug.cgi?id=689850

I think it doesn't happen with upstream ghostscript. I seem to remember installing a compiled-from-source ghostscript on a friend's machine fixed the delay. I think the bug is in ubuntu's version. I haven't got the time to test this at the moment (on work computers I cannot install custom stuff). But it might explain ghostscript's reaction.

disclaimer: It has been a while and I cannot remember if I installed AFPL or GPL ghostscript. I might be the bug is in the GPL version but not the AFPL version. Th AFPL version is fast, that's for sure.

I'm having the same problem (gs going to 100% and taking a long time) - perhaps this is the same issue as https://bugs.launchpad.net/ubuntu/+source/cups/+bug/289852

I have the same problem.
Printers:
- HP Laserjet 1200 CUPS+Gutenprint v5.2.3 attached by usb
- Epson Stylus Color 760 CUPS+Gutenprint v5.2.3 attached by usb
- Brother HL-5140 Foomatic/hl1250 attached by lpr (network)
This was on intrepit and now jaunty. The "server" has 1,2GB Ram and 1.4Ghz.

Configuration of cups was done using the web-interface.

When printing from Windows XP using samba, pages come out at once.
Wgen printing from Ubuntu Jaunty, it takes very long (1-30 minutes, depending on the document).
A single page from a PDF may take 1-2 Minutes, while 6 PDF-Pages containing scanned pictures take very long.
All documents are gray oder black/white.
Status says "processing".

"gs" takes 100% cpu for a while. After that the system seems to be idle and the printer-led flashes.
Printing starts minutes later whereby the printer only prints one page, stops, prints the next and so on.
It apears as if there is much data transferes to the printer? The original documents are not large (from 400kb to 5 Mb).

This problem makes printing almost impossible because you may have to wait half an hour to get your printout...

Since updating to the ghostscript package: 8.63.dfsg.1-0ubuntu6.3 (Intrepid Security) All the remaining printing problems that I had have resolved. 4x6 color prints sit in que for no more than 10-15 seconds and the printer starts instantly while the que is still open. As before, normal text or pdf documents print instantly. I have also updated my turboprint driver to the newer v 2.07, but I noticed the speed up with the older 1.x version driver as well. So, for me at least, this bug is finally closed. Here's hoping there are no regressions in Jaunty......

hm... normal documents (odt, text, etc) print instantly (2 seconds).
The cups test page starts after 8 seconds and the job has a size of 17k.

I noticed that printing a 7,5MB PDF (10 pages with scannend pages, no color) generates a 53MB job which of course takes time to process. This might be a problem of the client or application.
On the server, cups takes load for a short time, then gs, pdftops, sed, pstops in turn.

Appears to still be a problem for me on Jaunty, with ghostscript 8.64.dfsg.1-0ubuntu8.

Same here in Jaunty using Okular, printing to a Fedora-hosted CUPS server which has a USB printer.
Try to print the attached grinds for ~30minutes, with 'gs' at the top of 'top'. The CUPS printers page for the local machine (not the server) i.e. http://localhost:631/printers/ says "TurboPrint: printing page 5, 99% complete..." and ticks up the page count very slowly, then prints.

Used to be fine under earlier Ubuntu's, though I can't test with this exact PDF.

If you are using turboprint, there is a new version, 2.10-1 that addresses some specific issues with Jaunty. You may want to update your turboprint driver. I have had no problems at all with turboprint and a canon i960 after upgrading to Jaunty and the newest turboprint driver.

It's not a free upgrade from Turboprint 1.x to 2.x. I'll probably try the non-turboprint driver for my Canon PIxma iP4200 first.

I have the same problem with jaunty. (very slow photo printing)
could this be related?
http://www.linux-archive.org/ubuntu-development/311956-heavy-printing-regression-jaunty-sru.html

Arne Brix, do you have all updates applied to Jaunty, so that the fix of the problem you cite is present on your system? If not, please update now. Or did you update and this turned formerly fast photo printing to be too slow now?

Hello Till,
thank you for your lightning fast reply :-)
The Printer is a kyocera FS-C5100DN and used the ppd for linux
downloaded from the kyocera homepage.
Printing was fine using intrepid until some update broke it. (it's not
my computer that's affected, so i can not say which one it was exactly)
I tryed updating to the latest intrepid version, which didn't help.
I tryed updating to Jaunty (when it was final), which didn't help either.
I tryed updating again today (even activating proposed updates) which
didn't help.
I tryed using a different driver which displayed the same symptoms:
photos taking up to 20 minutes to print.
I print over network since the printer is in a different room but that
can't be the problem since it works fine under Windows.
If there is something i can do to diagnose the problem, please tell me.
I know close to nothing about cups and printing, but i have reasonable
experience with debian and ubuntu and know my way around the shell.

Greetings
      Arne

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Hi all, I can not tell, if my problem is related or a new one. The PC I use has a 2,4 Ghz AMD CPU and 512 MB of memory. The printer is a Canon S520, attached to a mini-printserver over LAN. All windows PCs in the network are printing like a charm, unlike the Ubuntu Karmic PC (above), that takes very long time to print pictures (b&w A4, for instance) or OO documents (haven't seen it printing an image yet in fact).
Since I am sharing this unpleasant experience with one of my children and have to print his homework on a windows machine, the pressure on me is really high to get this fixed.

PDF printing in Lucud is too slow. 15 page document stays in printing queue too long, pages are being printed with huge pauses. Probably it is "gs" process, which does some processing.

It's hard to tell what you mean by 'too sow'.
How long does it take ? is the document color or black and white ? Graphics or text ? At what resolution (dpi) ? What is your hardware spec. ?

Martin G Miller wrote:
> Since updating to the ghostscript package: 8.63.dfsg.1-0ubuntu6.3 (Intrepid Security) All the remaining
> printing problems that I had have resolved. So, for me at least, this bug is finally closed.

This bug report is being closed due to your last comment regarding this being fixed with an update. For future reference you can manage the status of your own bugs by clicking on the current status in the yellow line and then choosing a new status in the revealed drop down box. You can learn more about bug statuses at https://wiki.ubuntu.com/Bugs/Status. Thank you again for taking the time to report this bug and helping to make Ubuntu better. Please submit any future bugs you may find.

For other people who still experience slow printing it is better to file a seperate bug report with a good description of the problem and as a minimum the apport-collect information as described here: https://wiki.ubuntu.com/DebuggingPrintingProblems if you still can reproduce in a supported release, since it is difficult to tell without any further information if you are facing the same problem as Martin G Miller.

my printer prints things from Ubuntu very small. What is the fix for this?

Thanks,
Craig