+++ This bug was initially created as a clone of Bug #429897 +++ Description of problem: I'm experiencing similar symptoms to those described in Bug #429897 using openoffice.org-writer2.3.0-6.11.el5_4.1 under RHEL5. Specifically: under several different circumstances, I'm seeing this: "From a trace, it appears that OOo is fetching a blank shell command from the printer info, appending " 2>/dev/null" and executing that. This of course doesn't cause anything to be printed." Some of the circumstances under which this has been observed to occur include: - using the "Print File Directly" button (as in Bug #429897); - using "File -> Print" when Desktop Effects are enabled; - using "File -> Print" on print certain documents originally created with Microsoft Word; for some reason, the bug seems to happen only the first time the user tries to print during the Writer session (if Desktop Effects are not enabled). Version-Release number of selected component (if applicable): 2.3.0-6.11.el5_4.1 How reproducible: Always (via "Print File Directly") Steps to Reproduce: 1. Disable CUPS server 2. echo 'gtk-print-backends = "lpr,file"' >> /etc/gtk-2.0/gtkrc (alternatively: echo 'gtk-print-backends = "lpr,file"' >> $HOME/.gtkrc-2.0) 3. oowriter 4. type some characters (or paste a few pages of text) 5. Press the printer icon in the toolbar Actual results: If the document is very short, nothing happens (after the "Untitled1 is being printed on Generic Printer" dialog disappears, which is the "dialogue box [that] flashes up so quickly it can't be seen" described in Bug #429897). If the generated Postscript is large enough to produce a SIGPIPE when the empty shell command exits, a dialog box with the message "Error while printing" appears. In either case, no printout appears. Expected results: A printed document.
This problem still exists in Red Hat Enterprise Linux 5.5 with OpenOffice 3.1.1.
I've found that this bug may be related to CUPS printing. Disabling CUPS support via /usr/lib/openoffice.org3/program/spadmin (or by adding "DisableCUPS=true" to /usr/lib/openoffice.org/basis3.1/share/psprint/psprint.conf or $HOME/.openoffice.org/3/user/psprint/psprint.conf) seems to remove the symptom. I suspect that what is happening is that when OpenOffice puts up the Print dialog, it queries for CUPS printers in the background; however, when the query fails or times out, OpenOffice is clearing out the commands for all printers (including those supplied by other backends such as LPR). The reason the symptom is intermittent may be that it involves a race condition: larger documents that take a longer time to prepare would give more time for the CUPS query to fail.
Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.