Printing speed problem

This bug is easy to reproduce. Start a new virtual machine with 1GB of ram. Make a clean install of Ubuntu 10.10. Update. Add a network printer and print the attached document. I tested with an Officejet Pro 8000.

The page didn't print under the virtual machine. I've attached troubleshoot.txt from the printer problem wizard.

Hello Oliver
I confirm that running this test Ghostscript pull up cpu at 101%.

Architecture: amd64
CheckboxSubmission: ee7965142c8cf92c0ba2cd95fe7e857c
CheckboxSystem: 4ed15c40009aa6f7770f606350a390a2
DistroRelease: Ubuntu 10.10
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release amd64 (20101007)
Lpstat: device for Stylus-D92: usb://EPSON/Stylus%20D92
MachineType: Gigabyte Technology Co., Ltd. H55M-S2H
Package: ghostscript 8.71.dfsg.2-0ubuntu7
PackageArchitecture: amd64
Papersize: a4
PpdFiles: Stylus-D92: Epson Stylus D92 - CUPS+Gutenprint v5.2.6 Simplified
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.35-23-generic root=UUID=685b8f48-03d7-446b-bdbf-fb181446ca94 ro quiet splash
ProcEnviron:
 LANG=it_IT.utf8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.35-23.36-generic 2.6.35.7
Tags: maverick
Uname: Linux 2.6.35-23-generic x86_64
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare
dmi.bios.date: 12/03/2009
dmi.bios.vendor: Award Software International, Inc.
dmi.bios.version: F1
dmi.board.name: H55M-S2H
dmi.board.vendor: Gigabyte Technology Co., Ltd.
dmi.board.version: x.x
dmi.chassis.type: 3
dmi.chassis.vendor: Gigabyte Technology Co., Ltd.
dmi.modalias: dmi:bvnAwardSoftwareInternational,Inc.:bvrF1:bd12/03/2009:svnGigabyteTechnologyCo.,Ltd.:pnH55M-S2H:pvr:rvnGigabyteTechnologyCo.,Ltd.:rnH55M-S2H:rvrx.x:cvnGigabyteTechnologyCo.,Ltd.:ct3:cvr:
dmi.product.name: H55M-S2H
dmi.sys.vendor: Gigabyte Technology Co., Ltd.

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

Bug #568363 sounds very similar to this

Tested this document from inkscape (using print -> rendering -> backend -> vector) and Eye of gnome

Out of interest I tried the following:

1. Open stars.svg in inkscape, and 'print to file' as postscript
2. Open stars.ps in evince and print to printer
3. Successful print (correct and fast)
----

1. Open stars.svg in inkscape, and 'print to file' as PDF
2. Open stars.pdf in evince and print to printer
3. Manually cancelled print job after 22minutes
4. "gs stars.pdf" in terminal dies with 'unrecoverable error'

Oliver, note that "gs stars.pdf" defaults to the broken "x11alpha" output device. Use "gs -sDEVICE=x11 stars.pdf" instead.

I have tried with a Poppler-based pdftoraster which is currently under development at OpenPrinting and is under consideration to replace the current GhostScript-based pdftoraster.

starts.pdf from comment #20 and #21 takes 53 secs with Poppler-based pdftoraster instead of 10 minutes with GhostScript-based pdftoraster. The PDF file of comment #1 takes 2 minutes with the Poppler-based pdftoraster. The GhostScript-based pdftoraster is already running for 30 min on the PDF file of comment #1 and still running.

So the fix, at least for CUPS-Raster-based drivers will be the replacement of pdftoraster by the Poppler-based one.

Bug 355801 is not really a duplicate of this one, but the sample file attached there (after it got mangled by libcairo, attachment of comment #3) is also a good example for reproducing the slowness problem of Ghostscript.

Sorry, I meant bug 680628 in the previous comment.

Trying to print a 12 page calendar from PDF, started processing 24 minutes ago and no output so far.

Please retry with current Natty (Boot a live CD and do a full update during the live session to assure to have the current Ghostscript). Does printing/rendering your files get faster? At least some slownesses should be fixed in current Ghostscript 9.01.

This bug was fixed in the package cups - 1.4.5-3

---------------
cups (1.4.5-3) unstable; urgency=low

  [ Till Kamppeter ]
  * debian/rules: Do not remove the /usr/share/cups/model/ directory, some
    manufacturer-supplied printer drivers (like from Brother) still use it.
  * debian/rules: Remove a cost factor change for pstops. It is not used any
    more and overridden by
    pstops-based-workflow-only-for-printing-ps-on-a-ps-printer.dpatch
  * debian/local/filters/pdf-filters/filter/pdftoraster.cxx,
    debian/local/filters/pdf-filters/conf/pdftoraster.convs,
    debian/local/filters/pdf-filters/README,
    debian/local/filters/pdf-filters/addtocups
    debian/local/filters/pdf-filters/conf/HP-PhotoSmart_Pro_B8300-hpijs-pdftoijs.ppd,
    debian/local/filters/pdf-filters/config-scripts/cups-pdf-filters.m4,
    debian/local/filters/pdf-filters/removefromcups: Upstream changes of
    the PDF filter add-on package:
     o Added the Poppler-based pdftoraster filter. This filter is much faster
       than the Ghostscript-based filter (LP: #668800).
     o Cleaned up the sample PPD file for pdftoijs (does not go into the
       Debian/Ubuntu package of CUPS).
  * debian/rules: Rename the newly added Poppler-based pdftoraster filter
    to pdftoraster-poppler to not conflict with Ghostscript's pdftoraster
    and lower its cost factor so that it is prioritized against Ghostscript's
    filter.
  * debian/patches/cups-avahi.dpatch: Updated to fix assertion failure
    (LP: #707592, Red Hat bug #672143).

  [ Martin Pitt ]
  * debian/patches/ubuntu-upstart.dpatch: Don't ignore failures from
    apparmor-profile-load.

cups (1.4.5-2) unstable; urgency=low

  [ Till Kamppeter ]
  * debian/patches/cups-avahi.dpatch: Added patch from Tim Waugh from Red Hat
    to implement full Avahi support, not only for printer discovery by the
    "dnssd" backend but also for print queue broadcasting and browsing by the
    scheduler (CUPS daemon). Fixes LP: #465916.
  * debian/patches/dnssd-avahi.dpatch: Removed, is part of new
    cups-avahi.dpatch.
  * debian/patches/quiesce-bonjour-warning.dpatch: Removed, not needed any
    more with the new cups-avahi.dpatch.
  * debian/rules: Added "--with-local_protocols='CUPS dnssd'
    --with-remote_protocols='CUPS dnssd'" to the command line of "./configure".
    This adds support for DNS-SD-based browsing and broadcasting by default.
  * debian/patches/configure-default-browse-protocols.dpatch: Fixed handling
    of "--with-local_protocols=..." and "--with-remote_protocols=..." on the
    command line of "./configure". Now (quoted) values with spaces, like
    "CUPS dnssd" are treated correctly.
  * debian/patches/usb-backend-no-segfault-on-bad-device-id.dpatch: Assure
    that the device ID string read from a USB device can never be a mess: Try
    other byte order for device ID string length also if length is too small,
    empty the read device ID string if there is an IOCTL failure, reject ID
    strings with unprintable characters, clean white space in the ID string,
    and finally accept the empty ID string as an unknown device. This
    overcomes the problem that USB-to-Parallel adapter cables do not
    report...

The upstream developers of Ghostscript did several improvements concerning performance when rendering complex input files at high (printing) resolutions. These changes are all included in the upcoming Ghostscript 9.03 to be released in August and to be included in Oneiric. During this development cycle I will look into switching the Ghostscript package to the GIT snapshot already before the release so that there is more time for testing.

This bug was fixed in the package ghostscript - 9.04~dfsg~20110721-0ubuntu1

---------------
ghostscript (9.04~dfsg~20110721-0ubuntu1) oneiric; urgency=low

  * New upstream release
     - GIT snapshot from July, 21 2011.
     - Significant rendering speed improvement for printing PDF files (Upstream
       bug #691755, LP: #568363, LP: #668800).
  * debian/symbols.common: Updated for new upstream source. Applied patch
    which dpkg-gensymbols generated for debian/libgs9.symbols to this file.
 -- Till Kamppeter <email address hidden> Thu, 21 Jul 2011 18:05:03 +0200

We can get even by another factor of 12 faster (measured with stars.pdf), with ghostscript 9.04~dfsg~20110721-0ubuntu2

---------------
ghostscript (9.04~dfsg~20110721-0ubuntu2) oneiric; urgency=low

  * debian/patches/1001_gstoraster_nointerpolate.patch: Make CUPS filters
    call Ghostscript with the "-dNOINTERPOLATE" option. This makes the rendering
    of the input files by a factor of 12 faster. This should really eliminate
    all complaints of LP: #568363, LP: #668800, and other "printing too slow
    bugs".

 -- Till Kamppeter <email address hidden> Thu, 21 Jul 2011 20:55:03 +0200

In the next CUPS package (1.4.7-2) the priorities will get returned to make the Ghostscript-based gstoraster filter be used instead of the Poppler-based pdftoraster, the pdftops and pstopdf CUPS filters are switched to be Ghostscript-based, and also all Ghostscript calls defined in CUPS are done with "-dNOINTERPOLATE" now. Please test whether everything still works and how much faster it gets.

Correction for the version number: The next CUPS package will be 1.4.7-1ubuntu3.

I'm using the cups version 1.5.0-8ubuntu6 but the problem is still there. I need to print pdf from an other computer with an older version of ubuntu.

Ben, probably on your client your "older version of Ubuntu" is so old that bug 680628 is not fixed there. I recommend to update that version or use Adobe Reader instead of evince there.

I think this problem still exists in 12.04 Precise Pangolin Beta 1: When I try to print the attached document, Ghostscript runs at 100% on one CPU core (Intel core i5 2520) for ~10 minutes, taking sometimes more than 1GB RAM. The printing process is started from evince.
The printer is a Brother HL-2030 with the driver "Brother HL2030 for CUPS (grayscale, 2-sided printing)" (Ubuntu package brother-cups-wrapper-laser and brother-lpr-drivers-laser). The testpage prints fine.

If I try to print the same document with theFoomatic/hl1250 driver, printing works with pauses between pages, but often printing errors occur, which make this driver useless. Using the same driver in OpenSuse works perfectly, without any pauses between the pages!

Stefan, rendering slowness can get caused by many different factors, and many problems are solved by the fixes referenced in this bug report, but there still seem to be other cases which cause slownesses.

For your case I have reported the following bug to Ghostscript upstream:

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

Please subscribe to that bug report and answer the developers questions if needed. Thanks for your report and test file.

Stefan, your file was generated by Cairo, therefore I have also reported a bug to Cairo:

https://bugs.freedesktop.org/show_bug.cgi?id=48260

Stefan, are you able to provide the original pdf of that document instead of the version that has been printed to pdf using cairo ?

I am working on fixes for cairo to improve the output but I need the original pdf to test the fixes with, not the output that has already passed through cairo.

Sorry for taking so long to answer. Yes, here I send you the original file.

2012/4/6 Adrian Johnson <email address hidden>:
> Stefan, are you able to provide the original pdf of that document
> instead of the version that has been printed to pdf using cairo ?
>
> I am working on fixes for cairo to improve the output but I need the
> original pdf to test the fixes with, not the output that has already
> passed through cairo.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/668800
>
> Title:
>  Printing speed problem
>
> Status in GS-GPL  -  GPL Ghostscript:
>  Fix Released
> Status in “cups” package in Ubuntu:
>  Fix Released
> Status in “ghostscript” package in Ubuntu:
>  Fix Released
>
> Bug description:
>  Printing takes too long, or occasionally fails. During the print job,
>  process gs takes 100% cpu and printer pauses for a long time. This
>  happens on Ubuntu 10.04 32bit on a 500Mhz Pentium 3 with 312MB of ram,
>  on Ubuntu 10.10 64bit on a 2.4Ghz Q6600 quad core with 4GB of ram, and
>  on Ubuntu 10.10 32bit in a virtual machine with 1024MB of ram. Both
>  printers I have are affected. Officejet Pro 8000, Canon iP4500.
>  Printing is faster in 8.04 LTS.
>
>  The attached PDF seams to cause particular problems and takes about 10
>  minutes to print. The gs process is using 100% cpu all this time.  I'v
>  noticed that the drop shadows in the attached document aren't always
>  printed. But this document isn't the only one affected. Photos and web
>  pages also pause during printing in draft and photo print modes.
>
>  I read the instructions here
>  https://wiki.ubuntu.com/DebuggingPrintingProblems to disable apparmor
>  using 'sudo aa-complain cupsd' but this made no difference.
>
>  I've just tested an old Apple 8500 which is a postscript printer.
>  Printing takes a very long time to start, and process pdftops uses
>  100% cpu during all this time if this is of any relevence.
>
>  Printer test page works fine.
>
>  I've noticed this mainly affects documents with objects that are
>  blurred and transparent. Eg. create an object in inkscape and set
>  opacity to 80 and blur to 40; and the printer becomes lethargic. A
>  shape with opacity set to 100 and blur set to 0 prints in the blink of
>  an eye.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/gs-gpl/+bug/668800/+subscriptions

This is a bummer. I can't print PDFs on any of my 12.04 machines without getting 100% cpu from a "gs" process. Is there any workaround?

I have this problem too in 12.04 when trying to print from firefox either on a laser printer or to the PDF virtual printer

The problem in Precise (12.04) is most probably caused by switching the pdftops CUPS filter from Poppler to Ghostscript and allowing higher image rendering resolutions when the pdftops filter has to turn graphical structures of the PDF input file into bitmaps when converting to PostScript and PostScript does not support these structures.

I have uploaded a cups-filters package to precise-proposed now which switches back to Poppler and limits the image rendering resolution to 360 dpi. Please test the package as soon as it gets available for download and give feedback here. This is required to make the new package an official update for Precise. Another comment with testing instructions will get posted here.

With the new package you can also test the behavior when switching between use of Poppler and Ghostscript and changing the resolution limit. Run the following commands in a terminal window for switching between Ghostscript and Poppler:

lpadmin -p <printer> -o pdftops-renderer-default=gs
lpadmin -p <printer> -o pdftops-renderer-default=pdftops

and

lpadmin -p printer -R pdftops-renderer-default

to remove the setting. To change the resolution limit run a command like

lpadmin -p <printer> -o pdftops-max-image-resolution-default=1440

and set unlimited resolution via

lpadmin -p <printer> -o pdftops-max-image-resolution-default=0

or remove your setting with

lpadmin -p <printer> -R pdftops-max-image-resolution-default

Always replace "<printer>" by your printer's queue name (enter "lpstat -v" to find your printer's queue name).

See also

/usr/share/doc/cups-filters/README.txt.gz

See and tell us in this bug report which works best for you.

A debdiff of the changes is attached.

To the SRU team: The relevant changes for the fix are in the file filter/pdftops.c. The file in the debdiff looks very cluttered as there are many lines where only white space (indentation) changed. Attached to this comment is a cleaner diff for this file with white space changes ignored (diff -b), here one especially sees how the conditional compiling for Ghostscript/Poppler is replaced by "if"s so that the Ghostscript/Poppler decision can be made at run time.

Hello Oliver, or anyone else affected,

Accepted cups-filters into precise-proposed. The package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Another test you should try:

After having tested the proposed package without changing any default settings, run the following commands in a terminal window

lpadmin -p <printer> -o pdftops-renderer-default=gs
lpadmin -p <printer> -o pdftops-max-image-resolution-default=1440
lpadmin -p <printer> -o psdebug=true

with <printer> being the name of your print queue (You can find the name by ruuning the "lpstat -v" command).

After that try to print again. Does it work reasonably fast now? If it works and if it is still too slow, run

lpadmin -p <printer> -o pdftops-max-image-resolution-default=720

and try again. If it is still too slow, run

lpadmin -p <printer> -o pdftops-max-image-resolution-default=360

and try again.

Please report all your results here.

To get back to the default settings of the proposed package run the commands

lpadmin -p <printer> -R pdftops-renderer-default
lpadmin -p <printer> -R pdftops-max-image-resolution-default
lpadmin -p <printer> -R psdebug

I tried testing this.

I enabled proposed updates and selected cups-filters in the update manager.

Tested all the options but they don't seam to have any effect. The document took between 2 and 3 minutes in all cases. And i still see gs running when i expected to see pdftops when using default renderer.

I could be doing something wrong.

I tested using the first attachment in this bug on a 1.3GHz dual core laptop.

Oliver, for your printers pdftops is not used, so the new package and also the mentioned configuration changes do not affect your printing performance.

Taken bug out of SRU process for Precise, as user who has complained about problem in Precise did not answer (and is not owner of this bug).

This bug was fixed in the package cups-filters - 1.0.18-0ubuntu0.1

---------------
cups-filters (1.0.18-0ubuntu0.1) precise-proposed; urgency=low

  [ Till Kamppeter ]
  * New upstream release
     - pdftops: Allow selection whether Ghostscript or Poppler is used
       at runtime, setting the "pdftops-renderer" option to "gs" or
       "pdftops". This way one can switch to Poppler per-queue if there
       are incompatibilities with certain PostScript printers.
     - pdftops: Allow setting an upper limit for the image rendering
       resolution, also at runtime, setting the option
       "pdftops-max-image-resolution-default" to the desired limit in dpi.
       "0" means no limit.
     - pdftops: Fixed crash by wrong usage of sizeof() function when adding
       "Collate" to the fifth command line argument for the "pstops" CUPS
       filter call (LP: #982675).
     - pdftops: Removed newline from copies value when reading it from
       the "%%PDFTOPDFNumCopies" entry of the incoming PDF file.
     - pdftops: Silenced compiler warning about ignoring the return
       value of the write() function.
     - pdftops: Added a crash guard.
     - pdftops: Start determining the printing resolution with
       cupsRasterInterpretPPD(), this is the most reliable as often
       the choice names of the "Resolution" option are marketing names
       with higher numerical values than the actual resolution. Also
       ignore error exit values of cupsRasterInterpretPPD() as the
       function can error out after having found the resolution
       (LP: #984082).
     - pdftops: If printing resolution is determined by
       cupsRasterInterpretPPD() do not stick on 100 dpi if the
       resolution cannot be determined (LP: #984082).
  * debian/rules: Set default renderer for the pdftops filter to Poppler
    due to many printer's buggy interpreters having problems with GhostScript's
    PostScript and set image rendering resolution limit of the pdftops filter
    to 360 dpi to prevents slow processing by the printer if very high
    resolutions are used or if the printing resolution is mis-detected by the
    pdftops filter (LP: #668800, LP #951627 (comment #30), LP: #998087,
    LP: #992982 (comments #26, #27, #30, #31), LP: #997728, LP: #994477,
    LP: #998087, LP: #978120, LP: #862167).

  [ Didier Raboud ]
  * Drop libtiff5-dev, just use libtiff-dev, this fixes the FTBFS due to
    incompatibility with cups.
 -- Till Kamppeter <email address hidden> Wed, 16 May 2012 11:25:03 +0200

The last change in cups-filters is not actually fixing this bug. setting back to "Invalid" for the cups-filters task.

Problem is still here in Ubuntu 12.10 with cups-filters 1.0.24

In my case the printer is a postscript printer (hp3030). So I have to ask the question, WHY is the print system even calling ghostscript to interpret a postscript file when the printer is fully able to handle it for itself?

Simple test: Visit http://google.com/maps and print any street map.
On my system that takes 5-10 seconds under Windows 7 and several minutes under Ubuntu.

IMO this is a major Ubuntu workflow problem which really makes it difficult to get work done. I have to use a Windows VM to print documents with graphics, or even just a google map.