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 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