RE: [Bug 968785] Re: ghostscript runs for indefinitely long period of time when called by foomatic-rip
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 + > From: 968...@bugs.launchpad.net > To: markde...@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:bvnTOS
RE: [Bug 968785] Re: ghostscript runs for indefinitely long period of time when called by foomatic-rip
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 + > From: 968...@bugs.launchpad.net > To: markde...@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 ** Attachment added: "008094f83574e" https://bugs.launchpad.net/bugs/968785/+attachment/30005
RE: [Bug 968785] Re: ghostscript runs for indefinitely long period of time when called by foomatic-rip
** 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 3708lp3708 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 + > From: 968...@bugs.launchpad.net > To: markde...@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 >
