Apache OpenOffice (AOO) Bugzilla – Issue 23232
Command line printing should not require the window system
Last modified: 2007-08-01 15:37:24 UTC
Unix/Linux/*nix specific. When printing from the command line, OOo requires the window system to be accessible. This defeats many of the advantages of command line printing, and is technically unneccessary. Therefore this requirement should be eliminated. Note that I'm aware this is a hard one, because it probably involves substantial redesign. However, I think it should not be forgotten.
I agree that this would be desireable. We will put this on the table again if we have ressources for it.
cp->ssa: please take over
SSA: reassign to PL
This bug is still around in OO 2.*, so it should probably be bumped up. If I try printing with `openoffice -p filename.doc` from within an ssh session (with -X flag), the splashscreen shows, and then OO crashes.
That crash should be fixed, but has nothing to do with this issue. Since you have Xserver access (you even see the introbitmap) that cannot be the issue. If you have a reproducible bug, then please file a new issue for this. BTW: I fully agree, that printing without Xserver access would be a valuable feature.
It may be more urgent than you think. Think web-based print services where you can submit an ODF document for printing. Or remote print servers.
Now that I am back at my desktop, I can see that the file did in fact print. What I got was a warning anyway: > ** (process:12907): WARNING **: Unknown error forking main binary / abnormal early exit ... A little more testing showed that of the following: ->/usr/lib/openoffice/program/soffice.bin ->/usr/bin/soffice ->/usr/bin/openoffice ... only `openoffice -p` shows the splashscreen and subsequent warning. All of the scripts/binaries successfully print. Soo, ignore my previous comment, my issue is not bug-worthy.
*** Issue 74156 has been marked as a duplicate of this issue. ***
For all of you needing a way to work around this issue, here's my solution. However I strongly ask for a real solution/fix to this problem. #!/bin/sh if [ ! -f /tmp/Xvfb/Xvfb_screen0 ] ; then mkdir /tmp/Xvfb PATH=\$PATH:/usr/X11R6/bin DISPLAY= Xvfb :10 -screen 0 800x600x24 -fbdir /tmp/Xvfb/ & sleep 1 fi soffice -display :10 -p "$1" As I use this for batch printing, I don't care if the Xvfb is still running afterwards, as a new batch will be started soon anyway. Of course you could kill it after soffice quits. For more information what Xvfb does read Xvfb(1).
For all of you needing a way to work around this issue, here's my solution. However I strongly ask for a real solution/fix to this problem. #!/bin/sh if [ ! -f /tmp/Xvfb/Xvfb_screen0 ] ; then mkdir /tmp/Xvfb PATH=\$PATH:/usr/X11R6/bin DISPLAY= Xvfb :10 -screen 0 800x600x24 -fbdir /tmp/Xvfb/ & sleep 1 fi soffice -display :10 -p "\$1" As I use this for batch printing, I don't care if the Xvfb is still running afterwards, as a new batch will be started soon anyway. Of course you could kill it after soffice quits. For more information what Xvfb does read Xvfb(1).
For all of you needing a way to work around this issue, here's my solution. However I strongly ask for a real solution/fix to this problem. #!/bin/sh if \[ ! -f /tmp/Xvfb/Xvfb_screen0 \] ; then mkdir /tmp/Xvfb PATH=$PATH:/usr/X11R6/bin DISPLAY= Xvfb :10 -screen 0 800x600x24 -fbdir /tmp/Xvfb/ & sleep 1 fi soffice -display :10 -p "$1" As I use this for batch printing, I don't care if the Xvfb is still running afterwards, as a new batch will be started soon anyway. Of course you could kill it after soffice quits. For more information what Xvfb does read Xvfb(1).
For all of you needing a way to work around this issue, here's my solution. However I strongly ask for a real solution/fix to this problem. #!/bin/sh if [ ! -f /tmp/Xvfb/Xvfb_screen0 ] ; then mkdir /tmp/Xvfb PATH=$PATH:/usr/X11R6/bin DISPLAY= Xvfb :10 -screen 0 800x600x24 -fbdir /tmp/Xvfb/ & sleep 1 fi soffice -display :10 -p "$1" As I use this for batch printing, I don't care if the Xvfb is still running afterwards, as a new batch will be started soon anyway. Of course you could kill it after soffice quits. For more information what Xvfb does read Xvfb(1).
For all of you needing a way to work around this issue, here's my solution. However I strongly ask for a real solution/fix to this problem. A sample shell script is attached. As I use this for batch printing, I don't care if the Xvfb is still running afterwards, as a new batch will be started soon anyway. Of course you could kill it after soffice quits. For more information what Xvfb does read Xvfb(1).
with the headless plugin for vcl added in CWS mergesvp, this problem should be solved. Just add -headless on the commandline. No need for a running X11 server, but the X11 libraries are needed to satisfy the linker.
please verify in CWS mergesvp
verified in CWS mergesvp
seen in m233