This is something that causes a problem in our environment. We use thin-client
Xterminals. A Xterminal runs only the Xserver- the applications reside on a
different Linux/Unix central host. Only the graphics output are sent to the
Xserver, and the Xserver sends back mouse and keyboard events to the Xhost.
Start with a Writer or Draw document that contains partially transparent
objects. They can be simple transparent objects or transparency in frames. I
suspect it will also do this in Impress.
Next, try to print the document. You will be warned if you want to reduce
transparency. Answer "no", because you really want it. Now watch the network.
During a long wait, OpenOffice is apparently uses the Xserver to compute the
transparency rendering! It has to pass huge blocks of data from the application
to the Xserver. If you have a large or complex document, and a slower network,
the user can be "stuck" waiting for 5, 10, even 20 minutes! And during that
time, the network is saturated (possibly in both directions), preventing the
user from using other applications.
There seems to be a flaw in the design of OpenOffice that assumes the Xserver
will ALWAYS be local- running on the same machine as OpenOffice, itself. That
assumption is a violation of the [client/server] design model for the X Windows
System.
Granted, most modern OpenOffice users will have machines that run both the
Xserver and OpenOffice on the same machine, but it *can* cause problems for
people who use a thin model. With the current design, the speed of rendering is
tied directly to the speed of the network. I have a feeling it was just
"easier" to use some routines in the Xserver to do the transparency, instead of
writing new ones, and that most Unix/Linux users would never know.
Is there a way to stop using the Xserver to perform rendering for printing?

We need a virtual device (on X implemented using a Pixmap) to render the
transparent parts into a single bitmap which then can be printed. We'd need a
new implementation of virtual device using a local framebuffer to work around
that. This may even be useful in other situations, too, but I cannot promise
when anyone comes around to implementing this.

Actually, that is what I figured. It was probably far easier (and faster) at
the time to just render on the Xserver, since that was available and working.
Thin clients are nothing new, yet certainly not going away. Hopefully, one day
it can be fixed. There might already be methods for doing this in other *ix
applications... but I am not well versed in that area, so I can't know, either way.
Thanks for "listening" :)

This is Apache OpenOffice (AOO) Bugzilla: the Apache OpenOffice (AOO) bug system. In case
of problems with the functioning of Apache OpenOffice (AOO) Bugzilla, please contact
aoo-bugzilla-admin@apache.org.
Please Note: this e-mail address is only for reporting problems
with Apache OpenOffice (AOO) Bugzilla. Mail about any other subject will be silently
ignored.