Ubuntu
ghostscript package

ghostscript runs for indefinitely long period of time when called by foomatic-rip

Bug #968785 reported by Mark Desrousseaux on 2012-03-30

This bug affects 5 people

	Status	Importance	Assigned to	Milestone
cairo	Fix Released	High	freedesktop-bugs #48260
cairo (Ubuntu)	Fix Released	High	Unassigned	Ubuntu ubuntu-13.10
ghostscript (Ubuntu)	Invalid	High	Rolf Leggewie

Bug Description

I am printing to an HP Professional 1102. In had no success with HPLIP so am using foo2zjs instead. This works very well when printing from Libre Office which seems submits data to the print queue as an octet stream. Printing from evince/chromium/firefox however seems to submit data to print queue as PDF, which seems to result in a call by foomatic-rip to gs, which for most jobs other than text with no graphics runs for an indefinitely long period of time whilst utilising 100% CPU.

I did a "ps -ewf" to see what options gs is being called with and was able to confirm that manually running ghostscript from the command line against more or less any PDF file I have results in the same condition of an indefinitely long run period. A search on google came up with many very similar issues but they are all very old and supposedly already resolved. However, I took my inspiration from these old problem reports and tried inserting a -dNOTRANSPARENCY into the gs command line and found that this causes gs to complete its processing in one to two seconds and the resultant postscript output which I suppose would normally in the next stage be passed off to foo2zjs for further processing seems to be OK.

So to sum up, I can simulate the gs command from the command line, inserting an extra -dNOTRANSPARENCY switch and this seems to work around my problem with printing, but I cannot print from from any application other than Libre Office as I do not know how to tell foomatic-rip to pass this extra switch for me when it calls ghostscript (I guess this is hard-coded?)

What I would like, (if my understanding is so far correct) is ultimately a bug fix to ghostscript, and if this going to take a long time then perhaps in the meantime you could supply me with a way to insert that extra switch into the processing of my print jobs so I might perhaps have a usable workaround in the meantime.

Thank you for your time and consideration of my problem.....

*****************************
Other info:

shompoe@shompoe-TOSHIBA-NB305:~$ lsb_release -rd
Description: Ubuntu precise (development branch)
Release: 12.04

shompoe@shompoe-TOSHIBA-NB305:~$ apt-cache policy ghostscript
ghostscript:
  Installed: 9.05~dfsg-0ubuntu3
  Candidate: 9.05~dfsg-0ubuntu3
  Version table:
*** 9.05~dfsg-0ubuntu3 0
        500 http://ftp.sjtu.edu.cn/ubuntu/ precise/main amd64 Packages
        100 /var/lib/dpkg/status

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: ghostscript 9.05~dfsg-0ubuntu3
ProcVersionSignature: Ubuntu 3.2.0-20.32-generic 3.2.12
Uname: Linux 3.2.0-20-generic x86_64
ApportVersion: 1.95-0ubuntu1
Architecture: amd64
Date: Fri Mar 30 08:24:42 2012
Lpstat: device for HP-LaserJet-Pro-P1102: smb://MSHOME/REDROOM/Printer1102
MachineType: TOSHIBA TOSHIBA NB305
Papersize: a4
PpdFiles: HP-LaserJet-Pro-P1102: HP LaserJet Pro P1102 Foomatic/foo2zjs-z2 (recommended)
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-20-generic root=UUID=a705cec0-31d5-45f8-b7a3-f4b817016160 ro crashkernel=384M-2G:64M,2G-:128M apparmor=0 splash quiet vt.handoff=7
SourcePackage: ghostscript
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 03/16/2010
dmi.bios.vendor: TOSHIBA
dmi.bios.version: V1.40
dmi.board.name: NPVAA
dmi.board.vendor: TOSHIBA
dmi.board.version: 1.00
dmi.chassis.asset.tag: *
dmi.chassis.type: 10
dmi.chassis.vendor: TOSHIBA
dmi.chassis.version: N/A
dmi.modalias: dmi:bvnTOSHIBA:bvrV1.40:bd03/16/2010:svnTOSHIBA:pnTOSHIBANB305:pvrPLL3AL-001012:rvnTOSHIBA:rnNPVAA:rvr1.00:cvnTOSHIBA:ct10:cvrN/A:
dmi.product.name: TOSHIBA NB305
dmi.product.version: PLL3AL-001012
dmi.sys.vendor: TOSHIBA

Tags:

Related branches

lp:ubuntu/saucy-proposed/cairo

Revision history for this message

Mark Desrousseaux (markdesro) wrote on 2012-03-30:

BootDmesg.txt Edit (49.9 KiB, text/plain; charset="utf-8")
CurrentDmesg.txt Edit (2.2 KiB, text/plain; charset="utf-8")
Dependencies.txt Edit (1.5 KiB, text/plain; charset="utf-8")
Locale.txt Edit (319 bytes, text/plain; charset="utf-8")
Lspci.txt Edit (11.1 KiB, text/plain; charset="utf-8")
Lsusb.txt Edit (518 bytes, text/plain; charset="utf-8")
PrintingPackages.txt Edit (1.1 KiB, text/plain; charset="utf-8")
ProcCpuinfo.txt Edit (1.4 KiB, text/plain; charset="utf-8")
ProcEnviron.txt Edit (264 bytes, text/plain; charset="utf-8")
ProcInterrupts.txt Edit (1.4 KiB, text/plain; charset="utf-8")
ProcModules.txt Edit (2.7 KiB, text/plain; charset="utf-8")
UdevDb.txt Edit (108.9 KiB, text/plain; charset="utf-8")
UdevLog.txt Edit (245.8 KiB, text/plain; charset="utf-8")

Revision history for this message

Mark Desrousseaux (markdesro) wrote on 2012-03-30:

You will notice from PrintingPackages.txt that foo2zjs is not installed. This is because I removed this package and downloaded and installed it from foo2zjs.rkkda.com when I was initially trying to get my printer working.

Revision history for this message

Till Kamppeter (till-kamppeter) wrote on 2012-03-30:

You already went the correct way, finding a Ghostscript command line which reproduces the bug and playing with the command line options to make the problem go away, but for us to fix the bug and find a workaround for the time being, we need to reproduce the bug. So please post the Ghostscript command line with which you reproduced the bug and also post the input file which you have used. Tell us also how you obtained the input file (which application, which document file in the application, which operation in the application to get the input file). This information we will forward to the upstream developers of Ghostscript and they usually find a fix in some days.

Changed in ghostscript (Ubuntu):
status:	New → Incomplete

Till Kamppeter (till-kamppeter) on 2012-04-01

Changed in ghostscript (Ubuntu):
importance:	Undecided → High

Revision history for this message

Mark Desrousseaux (markdesro) wrote on 2012-04-02: RE: [Bug 968785] Re: ghostscript runs for indefinitely long period of time when called by foomatic-rip

Download full text (7.3 KiB)

****** Hi Till, thank you for your interest in this problem.
****** I just tried to print a web page (http://www.mindtools.com/pages/article/newPPM_94.htm)****** The print job is stuck in the print queue and gs is using 100% cpu...
shompoe@shompoe-TOSHIBA-NB305:~$ ps -e | grep gs 1225 ? 00:00:05 gnome-settings- 3708 ? 00:00:52 gs
shompoe@shompoe-TOSHIBA-NB305:~$ ps -efw | grep 3708lp 3708 3705 98 13:32 ? 00:01:05 gs -q -dNOPAUSE -dBATCH -dSAFER -sDEVICE=ps2write -sOUTPUTFILE=%stdout -dLanguageLevel=3 -dCompressFonts=false -dNoT3CCITT -dEncodeMonoImages=false -dEncodeColorImages=false -c save pop -f /var/spool/cups/tmp/00e794f7aa26fshompoe 3719 3554 0 13:33 pts/2 00:00:00 grep --color=auto 3708
shompoe@shompoe-TOSHIBA-NB305:~$ sudo cp /var/spool/cups/tmp/00e794f7aa26f .[sudo] password for shompoe:
********* next I deleted the print job through gnome so the print queue is empty********* and I confirmed with top command that gs process has terminated...
shompoe@shompoe-TOSHIBA-NB305:~$ sudo chown shompoe 00e794f7aa26f shompoe@shompoe-TOSHIBA-NB305:~$ sudo chmod 777 00e794f7aa26f shompoe@shompoe-TOSHIBA-NB305:~$ gs -q -dNOPAUSE -dBATCH -dSAFER -sDEVICE=ps2write -sOUTPUTFILE=%stdout -dLanguageLevel=3 -dCompressFonts=false -dNoT3CCITT -dEncodeMonoImages=false -dEncodeColorImages=false -c save pop -f 00e794f7aa26f > output.ps
********* gs process is using 100% cpu as before so I interrupt with CTRL+C...
shompoe@shompoe-TOSHIBA-NB305:~$ gs -q -dNOPAUSE -dBATCH -dSAFER -sDEVICE=ps2write -sOUTPUTFILE=%stdout -dLanguageLevel=3 -dCompressFonts=false -dNoT3CCITT -dEncodeMonoImages=false -dEncodeColorImages=false -dNOTRANSPARENCY -c save pop -f 00e794f7aa26f > output.ps
********* this time gs completes in about 2 - 3 seconds and the file output.ps opens in evince looking not identical but reasonable.
********* I hope you are able to reproduce this problem. It happens for me printing almost anything from firefox or evince unless it has really really simple graphics.

> Date: Fri, 30 Mar 2012 08:52:48 +0000
> From: <email address hidden>
> To: <email address hidden>
> Subject: [Bug 968785] Re: ghostscript runs for indefinitely long period of time when called by foomatic-rip
>
> You already went the correct way, finding a Ghostscript command line
> which reproduces the bug and playing with the command line options to
> make the problem go away, but for us to fix the bug and find a
> workaround for the time being, we need to reproduce the bug. So please
> post the Ghostscript command line with which you reproduced the bug and
> also post the input file which you have used. Tell us also how you
> obtained the input file (which application, which document file in the
> application, which operation in the application to get the input file).
> This information we will forward to the upstream developers of
> Ghostscript and they usually find a fix in some days.
>
>
> ** Changed in: ghostscript (Ubuntu)
> Status: New => Incomplete
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/968785
>
> Title:
> ghostscript runs for indefinitely ...

****** Hi Till, thank you for your interest in this problem.
****** I just tried to print a web page (http://www.mindtools.com/pages/article/newPPM_94.htm)****** The print job is stuck in the print queue and gs is using 100% cpu...
shompoe@shompoe-TOSHIBA-NB305:~$ ps -e | grep gs 1225 ?        00:00:05 gnome-settings- 3708 ?        00:00:52 gs
shompoe@shompoe-TOSHIBA-NB305:~$ ps -efw | grep 3708lp        3708  3705 98 13:32 ?        00:01:05 gs -q -dNOPAUSE -dBATCH -dSAFER -sDEVICE=ps2write -sOUTPUTFILE=%stdout -dLanguageLevel=3 -dCompressFonts=false -dNoT3CCITT -dEncodeMonoImages=false -dEncodeColorImages=false -c save pop -f /var/spool/cups/tmp/00e794f7aa26fshompoe   3719  3554  0 13:33 pts/2    00:00:00 grep --color=auto 3708
shompoe@shompoe-TOSHIBA-NB305:~$ sudo cp /var/spool/cups/tmp/00e794f7aa26f .[sudo] password for shompoe: 
*********  next I deleted the print job through gnome so the print queue is empty*********  and I confirmed with top command that gs process has terminated...
shompoe@shompoe-TOSHIBA-NB305:~$ sudo chown shompoe 00e794f7aa26f shompoe@shompoe-TOSHIBA-NB305:~$ sudo chmod 777 00e794f7aa26f shompoe@shompoe-TOSHIBA-NB305:~$ gs -q -dNOPAUSE -dBATCH -dSAFER -sDEVICE=ps2write -sOUTPUTFILE=%stdout -dLanguageLevel=3 -dCompressFonts=false -dNoT3CCITT -dEncodeMonoImages=false -dEncodeColorImages=false -c save pop -f 00e794f7aa26f > output.ps
********* gs process is using 100% cpu as before so I interrupt with CTRL+C...
shompoe@shompoe-TOSHIBA-NB305:~$ gs -q -dNOPAUSE -dBATCH -dSAFER -sDEVICE=ps2write -sOUTPUTFILE=%stdout -dLanguageLevel=3 -dCompressFonts=false -dNoT3CCITT -dEncodeMonoImages=false -dEncodeColorImages=false -dNOTRANSPARENCY -c save pop -f 00e794f7aa26f > output.ps
********* this time gs completes in about 2 - 3 seconds and the file output.ps opens in evince looking not identical but reasonable.
********* I hope you are able to reproduce this problem. It happens for me printing almost anything from firefox or evince unless it has really really simple graphics.

> Date: Fri, 30 Mar 2012 08:52:48 +0000
> From: 968785@bugs.launchpad.net
> To: markdesro@hotmail.com
> Subject: [Bug 968785] Re: ghostscript runs for indefinitely long period of	time when called by foomatic-rip
> 
> You already went the correct way, finding a Ghostscript command line
> which reproduces the bug and playing with the command line options to
> make the problem go away,  but for us to fix the bug and find a
> workaround for the time being, we need to reproduce the bug. So please
> post the Ghostscript command line with which you reproduced the bug and
> also post the input file which you have used. Tell us also how you
> obtained the input file (which application, which document file in the
> application, which operation in the application to get the input file).
> This information we will forward to the upstream developers of
> Ghostscript and they usually find a fix in some days.
> 
> 
> ** Changed in: ghostscript (Ubuntu)
>        Status: New => Incomplete
> 
> -- 
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/968785
> 
> Title:
>   ghostscript runs for indefinitely long period of time when called by
>   foomatic-rip
> 
> Status in “ghostscript” package in Ubuntu:
>   Incomplete
> 
> Bug description:
>   I am printing to an HP Professional 1102.   In had no success with
>   HPLIP so am using foo2zjs instead. This works very well when printing
>   from Libre Office which seems submits data to the print queue as an
>   octet stream. Printing from evince/chromium/firefox however seems to
>   submit data to print queue as PDF, which seems to result in a call by
>   foomatic-rip to gs, which for most jobs other than text with no
>   graphics runs for an indefinitely long period of time whilst utilising
>   100% CPU.
> 
>   I did a "ps -ewf" to see what options gs is being called with and was
>   able to confirm that manually running ghostscript from the command
>   line against more or less any PDF file I have results in the same
>   condition of an indefinitely long run period. A search on google came
>   up with many very similar issues but they are all very old and
>   supposedly already resolved. However, I took my inspiration from these
>   old problem reports and tried inserting a -dNOTRANSPARENCY into the gs
>   command line and found that this causes gs to complete its processing
>   in one to two seconds and the resultant postscript output which I
>   suppose would normally in the next stage be passed off to foo2zjs for
>   further processing seems to be OK.
> 
>   So to sum up, I can simulate the gs command from the command line,
>   inserting an extra -dNOTRANSPARENCY switch and this seems to work
>   around my problem with printing, but I cannot print from from any
>   application other than Libre Office as I do not know how to tell
>   foomatic-rip to pass this extra switch for me when it calls
>   ghostscript (I guess this is hard-coded?)
> 
>   What I would like, (if my understanding is so far correct) is
>   ultimately a bug fix to ghostscript, and if this going to take a long
>   time then perhaps in the meantime you could supply me with a way to
>   insert that extra switch into the processing of my print jobs so I
>   might perhaps have a usable workaround in the meantime.
> 
>   Thank you for your time and consideration of my problem.....
> 
>   *****************************
>   Other info:
> 
>   shompoe@shompoe-TOSHIBA-NB305:~$ lsb_release -rd
>   Description:	Ubuntu precise (development branch)
>   Release:	12.04
> 
>   
>   shompoe@shompoe-TOSHIBA-NB305:~$ apt-cache policy ghostscript
>   ghostscript:
>     Installed: 9.05~dfsg-0ubuntu3
>     Candidate: 9.05~dfsg-0ubuntu3
>     Version table:
>    *** 9.05~dfsg-0ubuntu3 0
>           500 http://ftp.sjtu.edu.cn/ubuntu/ precise/main amd64 Packages
>           100 /var/lib/dpkg/status
> 
>   ProblemType: Bug
>   DistroRelease: Ubuntu 12.04
>   Package: ghostscript 9.05~dfsg-0ubuntu3
>   ProcVersionSignature: Ubuntu 3.2.0-20.32-generic 3.2.12
>   Uname: Linux 3.2.0-20-generic x86_64
>   ApportVersion: 1.95-0ubuntu1
>   Architecture: amd64
>   Date: Fri Mar 30 08:24:42 2012
>   Lpstat: device for HP-LaserJet-Pro-P1102: smb://MSHOME/REDROOM/Printer1102
>   MachineType: TOSHIBA TOSHIBA NB305
>   Papersize: a4
>   PpdFiles: HP-LaserJet-Pro-P1102: HP LaserJet Pro P1102 Foomatic/foo2zjs-z2 (recommended)
>   ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-20-generic root=UUID=a705cec0-31d5-45f8-b7a3-f4b817016160 ro crashkernel=384M-2G:64M,2G-:128M apparmor=0 splash quiet vt.handoff=7
>   SourcePackage: ghostscript
>   UpgradeStatus: No upgrade log present (probably fresh install)
>   dmi.bios.date: 03/16/2010
>   dmi.bios.vendor: TOSHIBA
>   dmi.bios.version: V1.40
>   dmi.board.name: NPVAA
>   dmi.board.vendor: TOSHIBA
>   dmi.board.version: 1.00
>   dmi.chassis.asset.tag: *
>   dmi.chassis.type: 10
>   dmi.chassis.vendor: TOSHIBA
>   dmi.chassis.version: N/A
>   dmi.modalias: dmi:bvnTOSHIBA:bvrV1.40:bd03/16/2010:svnTOSHIBA:pnTOSHIBANB305:pvrPLL3AL-001012:rvnTOSHIBA:rnNPVAA:rvr1.00:cvnTOSHIBA:ct10:cvrN/A:
>   dmi.product.name: TOSHIBA NB305
>   dmi.product.version: PLL3AL-001012
>   dmi.sys.vendor: TOSHIBA
> 
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/ghostscript/+bug/968785/+subscriptions

Revision history for this message

Till Kamppeter (till-kamppeter) wrote on 2012-04-02:

Can you attach the input file, 00e794f7aa26f? Thanks.

Revision history for this message

In freedesktop.org Bugzilla #48260, Till Kamppeter (till-kamppeter) wrote on 2012-04-03:

For printing on Dabian and Ubuntu GTK/GNOME-based applications (like evince) generate PDF with Cairo and send it to CUPS. CUPS calls Ghostscript to convert this PDF into the printer's native data format.

Problem is that the PDF generated by Cairo renders very slowly with Ghostscript in the printing-typical resolutions of 600dpi and more.

This is caused by pointless use of transparency also if only opaque objects are drawn and in addition, the bounding boxes of the transparency groups are always the entire page. Since Ghostscript has to allocate memory to hold the raster data for each transparency the overall memory consumption can get multiples of the memory needed for th final page's raster data, making the machine swapping to the death.

Can this be improved? PDF-based printing got standard now.

Sample bug reports:

https://bugs.launchpad.net/ubuntu/+source/ghostscript/+bug/968785
https://bugs.launchpad.net/ubuntu/+source/ghostscript/+bug/668800 (comment #36)
http://bugs.ghostscript.com/show_bug.cgi?id=692959

Changed in cairo (Ubuntu):
status:	New → Incomplete
importance:	Undecided → High

Bug Watch Updater (bug-watch-updater) on 2012-04-03

Changed in cairo:
importance:	Unknown → High
status:	Unknown → Confirmed

Revision history for this message

In freedesktop.org Bugzilla #48260, Adrian Johnson (ajohnson-redneon) wrote on 2012-04-03:

The page sized bounding boxes problem has been fixed in 1.12.0. The use of transparency groups for opaque objects is something that can be improved.

Revision history for this message

In freedesktop.org Bugzilla #48260, Till Kamppeter (till-kamppeter) wrote on 2012-04-03:

#10

Can you give me a patch for 1.10.2 which I could apply to the Ubuntu Precise (12.04) package?

Revision history for this message

In freedesktop.org Bugzilla #48260, Adrian Johnson (ajohnson-redneon) wrote on 2012-04-03:

#11

There are too many changes.

Revision history for this message

Mark Desrousseaux (markdesro) wrote on 2012-04-04: RE: [Bug 968785] Re: ghostscript runs for indefinitely long period of time when called by foomatic-rip

008094f83574e Edit (332.8 KiB, application/octet-stream)

Download full text (4.7 KiB)

Already deleted it I'm afraid, but here is a new spool file from following the steps I outlined before. Ghostscript was stuck trying to process it as before.

> Date: Mon, 2 Apr 2012 08:55:54 +0000
> From: <email address hidden>
> To: <email address hidden>
> Subject: [Bug 968785] Re: ghostscript runs for indefinitely long period of time when called by foomatic-rip
>
> Can you attach the input file, 00e794f7aa26f? Thanks.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/968785
>
> Title:
> ghostscript runs for indefinitely long period of time when called by
> foomatic-rip
>
> Status in “ghostscript” package in Ubuntu:
> Incomplete
>
> Bug description:
> I am printing to an HP Professional 1102. In had no success with
> HPLIP so am using foo2zjs instead. This works very well when printing
> from Libre Office which seems submits data to the print queue as an
> octet stream. Printing from evince/chromium/firefox however seems to
> submit data to print queue as PDF, which seems to result in a call by
> foomatic-rip to gs, which for most jobs other than text with no
> graphics runs for an indefinitely long period of time whilst utilising
> 100% CPU.
>
> I did a "ps -ewf" to see what options gs is being called with and was
> able to confirm that manually running ghostscript from the command
> line against more or less any PDF file I have results in the same
> condition of an indefinitely long run period. A search on google came
> up with many very similar issues but they are all very old and
> supposedly already resolved. However, I took my inspiration from these
> old problem reports and tried inserting a -dNOTRANSPARENCY into the gs
> command line and found that this causes gs to complete its processing
> in one to two seconds and the resultant postscript output which I
> suppose would normally in the next stage be passed off to foo2zjs for
> further processing seems to be OK.
>
> So to sum up, I can simulate the gs command from the command line,
> inserting an extra -dNOTRANSPARENCY switch and this seems to work
> around my problem with printing, but I cannot print from from any
> application other than Libre Office as I do not know how to tell
> foomatic-rip to pass this extra switch for me when it calls
> ghostscript (I guess this is hard-coded?)
>
> What I would like, (if my understanding is so far correct) is
> ultimately a bug fix to ghostscript, and if this going to take a long
> time then perhaps in the meantime you could supply me with a way to
> insert that extra switch into the processing of my print jobs so I
> might perhaps have a usable workaround in the meantime.
>
> Thank you for your time and consideration of my problem.....
>
> *****************************
> Other info:
>
> shompoe@shompoe-TOSHIBA-NB305:~$ lsb_release -rd
> Description: Ubuntu precise (development branch)
> Release: 12.04
>
>
> shompoe@shompoe-TOSHIBA-NB305:~$ apt-cache policy ghostscript
> ghostscript:
> Installed: 9.05~dfsg-0ubuntu3
> Candidate: 9.05~dfsg-0ubuntu3
> Vers...

Already deleted it I'm afraid, but here is a new spool file from following the steps I outlined before. Ghostscript was stuck trying to process it as before.

> Date: Mon, 2 Apr 2012 08:55:54 +0000
> From: 968785@bugs.launchpad.net
> To: markdesro@hotmail.com
> Subject: [Bug 968785] Re: ghostscript runs for indefinitely long period of	time when called by foomatic-rip
> 
> Can you attach the input file, 00e794f7aa26f? Thanks.
> 
> -- 
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/968785
> 
> Title:
>   ghostscript runs for indefinitely long period of time when called by
>   foomatic-rip
> 
> Status in “ghostscript” package in Ubuntu:
>   Incomplete
> 
> Bug description:
>   I am printing to an HP Professional 1102.   In had no success with
>   HPLIP so am using foo2zjs instead. This works very well when printing
>   from Libre Office which seems submits data to the print queue as an
>   octet stream. Printing from evince/chromium/firefox however seems to
>   submit data to print queue as PDF, which seems to result in a call by
>   foomatic-rip to gs, which for most jobs other than text with no
>   graphics runs for an indefinitely long period of time whilst utilising
>   100% CPU.
> 
>   I did a "ps -ewf" to see what options gs is being called with and was
>   able to confirm that manually running ghostscript from the command
>   line against more or less any PDF file I have results in the same
>   condition of an indefinitely long run period. A search on google came
>   up with many very similar issues but they are all very old and
>   supposedly already resolved. However, I took my inspiration from these
>   old problem reports and tried inserting a -dNOTRANSPARENCY into the gs
>   command line and found that this causes gs to complete its processing
>   in one to two seconds and the resultant postscript output which I
>   suppose would normally in the next stage be passed off to foo2zjs for
>   further processing seems to be OK.
> 
>   So to sum up, I can simulate the gs command from the command line,
>   inserting an extra -dNOTRANSPARENCY switch and this seems to work
>   around my problem with printing, but I cannot print from from any
>   application other than Libre Office as I do not know how to tell
>   foomatic-rip to pass this extra switch for me when it calls
>   ghostscript (I guess this is hard-coded?)
> 
>   What I would like, (if my understanding is so far correct) is
>   ultimately a bug fix to ghostscript, and if this going to take a long
>   time then perhaps in the meantime you could supply me with a way to
>   insert that extra switch into the processing of my print jobs so I
>   might perhaps have a usable workaround in the meantime.
> 
>   Thank you for your time and consideration of my problem.....
> 
>   *****************************
>   Other info:
> 
>   shompoe@shompoe-TOSHIBA-NB305:~$ lsb_release -rd
>   Description:	Ubuntu precise (development branch)
>   Release:	12.04
> 
>   
>   shompoe@shompoe-TOSHIBA-NB305:~$ apt-cache policy ghostscript
>   ghostscript:
>     Installed: 9.05~dfsg-0ubuntu3
>     Candidate: 9.05~dfsg-0ubuntu3
>     Version table:
>    *** 9.05~dfsg-0ubuntu3 0
>           500 http://ftp.sjtu.edu.cn/ubuntu/ precise/main amd64 Packages
>           100 /var/lib/dpkg/status
> 
>   ProblemType: Bug
>   DistroRelease: Ubuntu 12.04
>   Package: ghostscript 9.05~dfsg-0ubuntu3
>   ProcVersionSignature: Ubuntu 3.2.0-20.32-generic 3.2.12
>   Uname: Linux 3.2.0-20-generic x86_64
>   ApportVersion: 1.95-0ubuntu1
>   Architecture: amd64
>   Date: Fri Mar 30 08:24:42 2012
>   Lpstat: device for HP-LaserJet-Pro-P1102: smb://MSHOME/REDROOM/Printer1102
>   MachineType: TOSHIBA TOSHIBA NB305
>   Papersize: a4
>   PpdFiles: HP-LaserJet-Pro-P1102: HP LaserJet Pro P1102 Foomatic/foo2zjs-z2 (recommended)
>   ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-20-generic root=UUID=a705cec0-31d5-45f8-b7a3-f4b817016160 ro crashkernel=384M-2G:64M,2G-:128M apparmor=0 splash quiet vt.handoff=7
>   SourcePackage: ghostscript
>   UpgradeStatus: No upgrade log present (probably fresh install)
>   dmi.bios.date: 03/16/2010
>   dmi.bios.vendor: TOSHIBA
>   dmi.bios.version: V1.40
>   dmi.board.name: NPVAA
>   dmi.board.vendor: TOSHIBA
>   dmi.board.version: 1.00
>   dmi.chassis.asset.tag: *
>   dmi.chassis.type: 10
>   dmi.chassis.vendor: TOSHIBA
>   dmi.chassis.version: N/A
>   dmi.modalias: dmi:bvnTOSHIBA:bvrV1.40:bd03/16/2010:svnTOSHIBA:pnTOSHIBANB305:pvrPLL3AL-001012:rvnTOSHIBA:rnNPVAA:rvr1.00:cvnTOSHIBA:ct10:cvrN/A:
>   dmi.product.name: TOSHIBA NB305
>   dmi.product.version: PLL3AL-001012
>   dmi.sys.vendor: TOSHIBA
> 
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/ghostscript/+bug/968785/+subscriptions

Revision history for this message

Till Kamppeter (till-kamppeter) wrote on 2012-04-04:

I have tried this file with your command lines from comment #4 and without -dNOTRANSPARENCY it takes around 70 sec to finish, with -dNOTRANSPARENCY it takes less than a second. We cannot use -dNOTRANSPARENCY as the results come out incorrectly, in your file separator lines get black bars.

Revision history for this message

Mark Desrousseaux (markdesro) wrote on 2012-04-08: RE: [Bug 968785] Re: ghostscript runs for indefinitely long period of time when called by foomatic-rip

#12

Download full text (5.2 KiB)

Thanks Till, On my atom laptop it takes a lot lot lot longer. I appreciate the work you are doing. Thanks again. I would still appreciate the option to use no transparency for now and just take my chances until this is improved in a later release. just a quick edit to the code and recompile it right?...

> Date: Wed, 4 Apr 2012 10:44:40 +0000
> From: <email address hidden>
> To: <email address hidden>
> Subject: [Bug 968785] Re: ghostscript runs for indefinitely long period of time when called by foomatic-rip
>
> I have tried this file with your command lines from comment #4 and
> without -dNOTRANSPARENCY it takes around 70 sec to finish, with
> -dNOTRANSPARENCY it takes less than a second. We cannot use
> -dNOTRANSPARENCY as the results come out incorrectly, in your file
> separator lines get black bars.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/968785
>
> Title:
> ghostscript runs for indefinitely long period of time when called by
> foomatic-rip
>
> Status in Cairo Graphics Library:
> Confirmed
> Status in “cairo” package in Ubuntu:
> Incomplete
> Status in “ghostscript” package in Ubuntu:
> Incomplete
>
> Bug description:
> I am printing to an HP Professional 1102. In had no success with
> HPLIP so am using foo2zjs instead. This works very well when printing
> from Libre Office which seems submits data to the print queue as an
> octet stream. Printing from evince/chromium/firefox however seems to
> submit data to print queue as PDF, which seems to result in a call by
> foomatic-rip to gs, which for most jobs other than text with no
> graphics runs for an indefinitely long period of time whilst utilising
> 100% CPU.
>
> I did a "ps -ewf" to see what options gs is being called with and was
> able to confirm that manually running ghostscript from the command
> line against more or less any PDF file I have results in the same
> condition of an indefinitely long run period. A search on google came
> up with many very similar issues but they are all very old and
> supposedly already resolved. However, I took my inspiration from these
> old problem reports and tried inserting a -dNOTRANSPARENCY into the gs
> command line and found that this causes gs to complete its processing
> in one to two seconds and the resultant postscript output which I
> suppose would normally in the next stage be passed off to foo2zjs for
> further processing seems to be OK.
>
> So to sum up, I can simulate the gs command from the command line,
> inserting an extra -dNOTRANSPARENCY switch and this seems to work
> around my problem with printing, but I cannot print from from any
> application other than Libre Office as I do not know how to tell
> foomatic-rip to pass this extra switch for me when it calls
> ghostscript (I guess this is hard-coded?)
>
> What I would like, (if my understanding is so far correct) is
> ultimately a bug fix to ghostscript, and if this going to take a long
> time then perhaps in the meantime you could supply me with a way to
> insert that extra switch into the processing of my...

Thanks Till,   On my atom laptop it takes a lot lot lot longer. I appreciate the work you are doing. Thanks again.  I would still appreciate the option to use no transparency for now and just take my chances until this is improved in a later release.  just a quick edit to the code and recompile it right?...

> Date: Wed, 4 Apr 2012 10:44:40 +0000
> From: 968785@bugs.launchpad.net
> To: markdesro@hotmail.com
> Subject: [Bug 968785] Re: ghostscript runs for indefinitely long period of	time when called by foomatic-rip
> 
> I have tried this file with your command lines from comment #4 and
> without -dNOTRANSPARENCY it takes around 70 sec to finish, with
> -dNOTRANSPARENCY it takes less than a second. We cannot use
> -dNOTRANSPARENCY as the results come out incorrectly, in your file
> separator lines get black bars.
> 
> -- 
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/968785
> 
> Title:
>   ghostscript runs for indefinitely long period of time when called by
>   foomatic-rip
> 
> Status in Cairo Graphics Library:
>   Confirmed
> Status in “cairo” package in Ubuntu:
>   Incomplete
> Status in “ghostscript” package in Ubuntu:
>   Incomplete
> 
> Bug description:
>   I am printing to an HP Professional 1102.   In had no success with
>   HPLIP so am using foo2zjs instead. This works very well when printing
>   from Libre Office which seems submits data to the print queue as an
>   octet stream. Printing from evince/chromium/firefox however seems to
>   submit data to print queue as PDF, which seems to result in a call by
>   foomatic-rip to gs, which for most jobs other than text with no
>   graphics runs for an indefinitely long period of time whilst utilising
>   100% CPU.
> 
>   I did a "ps -ewf" to see what options gs is being called with and was
>   able to confirm that manually running ghostscript from the command
>   line against more or less any PDF file I have results in the same
>   condition of an indefinitely long run period. A search on google came
>   up with many very similar issues but they are all very old and
>   supposedly already resolved. However, I took my inspiration from these
>   old problem reports and tried inserting a -dNOTRANSPARENCY into the gs
>   command line and found that this causes gs to complete its processing
>   in one to two seconds and the resultant postscript output which I
>   suppose would normally in the next stage be passed off to foo2zjs for
>   further processing seems to be OK.
> 
>   So to sum up, I can simulate the gs command from the command line,
>   inserting an extra -dNOTRANSPARENCY switch and this seems to work
>   around my problem with printing, but I cannot print from from any
>   application other than Libre Office as I do not know how to tell
>   foomatic-rip to pass this extra switch for me when it calls
>   ghostscript (I guess this is hard-coded?)
> 
>   What I would like, (if my understanding is so far correct) is
>   ultimately a bug fix to ghostscript, and if this going to take a long
>   time then perhaps in the meantime you could supply me with a way to
>   insert that extra switch into the processing of my print jobs so I
>   might perhaps have a usable workaround in the meantime.
> 
>   Thank you for your time and consideration of my problem.....
> 
>   *****************************
>   Other info:
> 
>   shompoe@shompoe-TOSHIBA-NB305:~$ lsb_release -rd
>   Description:	Ubuntu precise (development branch)
>   Release:	12.04
> 
>   
>   shompoe@shompoe-TOSHIBA-NB305:~$ apt-cache policy ghostscript
>   ghostscript:
>     Installed: 9.05~dfsg-0ubuntu3
>     Candidate: 9.05~dfsg-0ubuntu3
>     Version table:
>    *** 9.05~dfsg-0ubuntu3 0
>           500 http://ftp.sjtu.edu.cn/ubuntu/ precise/main amd64 Packages
>           100 /var/lib/dpkg/status
> 
>   ProblemType: Bug
>   DistroRelease: Ubuntu 12.04
>   Package: ghostscript 9.05~dfsg-0ubuntu3
>   ProcVersionSignature: Ubuntu 3.2.0-20.32-generic 3.2.12
>   Uname: Linux 3.2.0-20-generic x86_64
>   ApportVersion: 1.95-0ubuntu1
>   Architecture: amd64
>   Date: Fri Mar 30 08:24:42 2012
>   Lpstat: device for HP-LaserJet-Pro-P1102: smb://MSHOME/REDROOM/Printer1102
>   MachineType: TOSHIBA TOSHIBA NB305
>   Papersize: a4
>   PpdFiles: HP-LaserJet-Pro-P1102: HP LaserJet Pro P1102 Foomatic/foo2zjs-z2 (recommended)
>   ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-20-generic root=UUID=a705cec0-31d5-45f8-b7a3-f4b817016160 ro crashkernel=384M-2G:64M,2G-:128M apparmor=0 splash quiet vt.handoff=7
>   SourcePackage: ghostscript
>   UpgradeStatus: No upgrade log present (probably fresh install)
>   dmi.bios.date: 03/16/2010
>   dmi.bios.vendor: TOSHIBA
>   dmi.bios.version: V1.40
>   dmi.board.name: NPVAA
>   dmi.board.vendor: TOSHIBA
>   dmi.board.version: 1.00
>   dmi.chassis.asset.tag: *
>   dmi.chassis.type: 10
>   dmi.chassis.vendor: TOSHIBA
>   dmi.chassis.version: N/A
>   dmi.modalias: dmi:bvnTOSHIBA:bvrV1.40:bd03/16/2010:svnTOSHIBA:pnTOSHIBANB305:pvrPLL3AL-001012:rvnTOSHIBA:rnNPVAA:rvr1.00:cvnTOSHIBA:ct10:cvrN/A:
>   dmi.product.name: TOSHIBA NB305
>   dmi.product.version: PLL3AL-001012
>   dmi.sys.vendor: TOSHIBA
> 
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/cairo/+bug/968785/+subscriptions

Revision history for this message

Till Kamppeter (till-kamppeter) wrote on 2012-08-02:

#13

Tested again with Ghostscript 9.06 on Quantal, on a laptop with dual core, 8GB and SSD and it took 20 sec to process.

till@till-desktop:~$ time gs -q -dNOPAUSE -dBATCH -dSAFER -sDEVICE=ps2write -sOUTPUTFILE=%stdout -dLanguageLevel=3 -dCompressFonts=false -dNoT3CCITT -dEncodeMonoImages=false -dEncodeColorImages=false -c save pop -f 008094f83574e > output.ps

real 0m20.041s
user 0m16.849s
sys 0m3.136s
till@till-desktop:~$

Revision history for this message

In freedesktop.org Bugzilla #48260, Till Kamppeter (till-kamppeter) wrote on 2013-03-07:

#14

To make printing also working well on mobile and generally low-performance devices it gets very important to completely do away with transparency in PDF output, at least if the document does not actually contain any transparent graphical elements.

We should perhaps even make one output mode optimized for printing with no transparency at all. This would allow fast print rendering, especially also on mobile. Ghostscript developers suggest PDF/X-1 output here.

Another mode could use transparency only where it is actually needed, for getting small, efficient PDF files for archiving and web download.

We should raise priority for this as slow printing is a very common problem under Linux (and mostly caused by the transparency abuse in Cairo output) and Linux gets more and more used on mobile battery-driven devices.

Revision history for this message

In freedesktop.org Bugzilla #48260, Till Kamppeter (till-kamppeter) wrote on 2013-03-25:

#15

More Ubuntu bug reports showing this problem:

https://bugs.launchpad.net/bugs/980616
https://bugs.launchpad.net/bugs/1159452

Revision history for this message

In freedesktop.org Bugzilla #48260, Psychon-d (psychon-d) wrote on 2013-08-21:

#16

If I understand this correctly, this was fixed with cairo 1.12. At least Adrian claims so and no one claimed anything else.

Bug Watch Updater (bug-watch-updater) on 2013-08-25

Changed in cairo:
status:	Confirmed → Fix Released

Revision history for this message

In freedesktop.org Bugzilla #48260, Adrian Johnson (ajohnson-redneon) wrote on 2013-09-11:

#17

I've pushed out a fix to make transparency groups normal groups when the content is opaque.

Revision history for this message

In freedesktop.org Bugzilla #48260, Till Kamppeter (till-kamppeter) wrote on 2013-09-16:

#19

Adrian, can you post the patch or tell which commit it is, so that I can apply it to the current Poppler in Ubuntu?

Revision history for this message

In freedesktop.org Bugzilla #48260, Psychon-d (psychon-d) wrote on 2013-09-16:

#20

Apply to Poppler? This is a bug about cairo...?

The commit that Adrian meant is:
http://cgit.freedesktop.org/cairo/commit/?id=8addb4798c918000eaa6f6dab138e0abb0efa946

And the following two patches fix some problems with it:
http://cgit.freedesktop.org/cairo/commit/?id=a6f51fed985f7db37c672bab0b5dab3f89e78282
http://cgit.freedesktop.org/cairo/commit/?id=279d5a2ed1aaa6d5dbfbeab9e4b4ffa6a66aa6f3

No idea if this can be backported sanely to older cairo versions, good luck.

Revision history for this message

In freedesktop.org Bugzilla #48260, Adrian Johnson (ajohnson-redneon) wrote on 2013-09-16:

#21

I have not tried it but I expect those three patches should apply to 1.12.4 or later as not much has changed since then.

I would also recommend applying this patch to improve printing performance:

http://cgit.freedesktop.org/cairo/commit/?id=266d6e71566ac8c5e360c0b32fb78e23e6a06168

This patch fixes the embedding of jpeg data in the pdf output. Without it the file size will be a lot larger.

Revision history for this message

In freedesktop.org Bugzilla #48260, Adrian Johnson (ajohnson-redneon) wrote on 2013-09-16:

#22

> I have not tried it but I expect those three patches should apply to 1.12.4
> or later

That should be 1.12.14 or later.

Revision history for this message

Till Kamppeter (till-kamppeter) wrote on 2013-09-16:

#18

cairo_1.12.16-0ubuntu1_1.12.16-0ubuntu2.debdiff Edit (25.2 KiB, text/plain)

Attached is a debdiff applying the fix of the upstream bug to the current Saucy package of Cairo in Ubuntu. Please upload this package.

Changed in cairo (Ubuntu):
status:	Incomplete → In Progress
status:	In Progress → Fix Committed
milestone:	none → ubuntu-13.10

Revision history for this message

In freedesktop.org Bugzilla #48260, Till Kamppeter (till-kamppeter) wrote on 2013-09-16:

#23

Thank you very much, the patches apply perfectly on Ubuntu's Cairo package (1.12.16). I have applied them to the Ubuntu package now.

Revision history for this message

Launchpad Janitor (janitor) wrote on 2013-09-27:

#24

This bug was fixed in the package cairo - 1.12.16-0ubuntu2

---------------
cairo (1.12.16-0ubuntu2) saucy; urgency=low

  * debian/patches/pdf-output-avoid-transparency.patch: PDF output: Avoid
    making groups a transparency group if not required (LP: #668800,
    LP: #968785, LP: #980616, LP: #1159452, upstream bug #48260).
  * debian/patches/pdf-output-mime-data-embedding.patch: PDF output: Fix
    embedding of mime data, improves printing performance especially on
    PDF output with embedded JPEG (Upstream bug #48260, comment #10).
-- Till Kamppeter <email address hidden> Mon, 16 Sep 2012 10:28:27 +0200

Changed in cairo (Ubuntu):
status:	Fix Committed → Fix Released

Revision history for this message

Rolf Leggewie (r0lf) wrote on 2015-04-04:

#25

Anything left to be done for ghostscript?

Changed in ghostscript (Ubuntu):
assignee:	nobody → Rolf Leggewie (r0lf)

Rolf Leggewie (r0lf) on 2016-11-20

Changed in ghostscript (Ubuntu):
status:	Incomplete → Invalid

Report a bug

This report contains Public information

Everyone can see this information.

You are

Subscribing...

Edit bug mail

Other bug subscribers

Patches

cairo_1.12.16-0ubuntu1_1.12.16-0ubuntu2.debdiff Edit

Add patch

Remote bug watches

freedesktop-bugs #48260
[RESOLVED FIXED] Edit
gs-afpl-bugzilla #692959
[RESOLVED FIXED] Edit

Bug watches keep track of this bug in other bug trackers.

Ubuntughostscript package

ghostscript runs for indefinitely long period of time when called by foomatic-rip

Bug Description

Related branches

Other bug subscribers

Patches

Bug attachments

Remote bug watches

Ubuntu
ghostscript package