Powerpoint + PostScript + CUPS

Paul Landers j.paul.landers at gmail.com
Thu Jun 25 08:47:48 PDT 2009


This is not strictly a CUPS issue, but I wanted to post it because of it's definite impact on CUPS.  I have obtained a sample Microsoft PowerPoint presentation that behaves normally until it is printed.  It consistently crashes the printing system if printed using PostScript, but prints normally using PCL.  Here are the 2 scenarios:

Scenario 1 (Windows):

PowerPoint presentation, file size 1MB, 31 slides.
Print to an HP Laserjet 4000N or a Laserjet 4100, PostScript.
Spool file size is 11MB.
After about 1MB of data transfer the job fails.
The data light on the printer continues flashing until the printer is powered OFF.
The job can be killed manually in the Windows printer queue

Repeating the above test using PCL the spool file size is 65MB, but it prints normally.


Scenario 2 (CUPS):

Repeat the above 2 tests, but instead of printing directly to the network printer, print IPP from the Windows XP box to a CUPS 1.3.10 server on Debian Lenny (raw queue) to the same 2 network printers:

The PCL job again prints fine to either printer.

The PostScript job again fails, and the printer data light flashes until powered OFF.
Here is the bad part:
CUPS reports the job(s) completed.
On the Linux CUPS server, the 'top' command shows an orphaned PID named "socket" that is consuming 100% of CPU until it is killed.
If the user sends multiple copies of the same problematic job, then multiple orphaned PIDs are present, dividing the 100% CPU among themselves until all are killed.

My point in this posting is that:

1. CUPS reports the job 'complete' when it never actually printed.
2. Any unrelated jobs that were sent behind the problematic job are also reported as complete, but were in fact lost too and never printed.
3. There is no CUPS GUI method for average users to recover from the problem (i.e. kill the orphaned PIDs).

Comments and suggestions?

Thanks!




More information about the cups mailing list