Apache OpenOffice (AOO) Bugzilla – Issue 17374
Pipe to kprinter no longer works
Last modified: 2010-03-25 16:36:07 UTC
I am not certain if this is the right section, but strange problems have arisen since OOo1.1 Beta2 with my printing. Since I cannot find an openoffice driver for my epson Photo 2200, and just for simplicity's sake, I pipe all of my print jobs to kprinter. I simply run ./spadmin, then put "kprinter" under "Select command". I have a post on the Gentoo forums regarding this: http://forums.gentoo.org/viewtopic.php?t=67998&highlight= It has done it to me now on three different machines. I would like upgrade the version of OO used at my office (I have several users on a thin-clients), but I cannot do it if this does not work. Please take a look at the Gentoo forum post at the link above, you will see what I mean. Thank you. Chris
Using ./spadmin in Linux, I find I can use qtcups, kprinter or kprinter --stdin. With 1.1beta2, they worked inconsistently, but with 1.1RC1 there have been no troubles. All of them work flawlessly.
reassign to me
i cannot reproduce the problem; kprinter works just fine for me and it comes up with its normal UI. This must have something to do with the environment kprinter is started with; but the specific cause eludes me. Question: you say, root can do this as expected; did you do a normal two setp setup (network setup firstm then workstation setup for the user) ? I just ask because not doing that is a common mistake and all kinds of weird things can happen if you don't.
Well, The weird thing is that root could do it on that one system at the time of that writing, but the other systems I have tried to do this on have not worked for anyone -- and I have set up 4 of them so far. The one system it *did* work on, wound up destroying kprinter all together. I had to recompile kdebase to get it working again. It works fine with the first beta and prior, however, on the very same machines with the very same environment. Something had to have changed about the way OO prints... The only thing I could do is uninstall anything later than beta1 and reinstall beta1 -- then it works. I have tried installing OO both as gentoo would have it (with emerge) and with the standard installer with the same results. If I had to guess, it looks like it was sending some sort of binary information where kprinter expected ascii, but that is just a guess. Did you see the picture of it on the link I included? Very strange. Chris
I did see the picture; but the only things i can think of are that kprinter either does not find its localized strings (not probable, there should be english as a default) or that it does not find a font to display its UI (strange, too). I don't think that kprinter gets binary data from OOo as i don't see how that would be possible; only plain 7bit PostScript goes to the print command. The only thing besides that would indeed be the pipe, but that is simply created using the popen call from libc; do you use an experimental version of glibc ?
I use glibc-2.3.2. If I print the job to a file then do something like this: echo job.ps |kprinter or echo job.ps |kprinter --stdin either works fine... Which is why I was thinking it has something to do with OO beta2 and up, and not Kprinter. Kprinter still works normally with apps like xpdf and mozilla... It is possible that it is my version of glibc... but why would it only do this on the *newer* versions of OO? If I can get my hands on another decent box, I can try to install it again... but after 4 times, I don't expect it will work :0(. I would compile OO from source to see if that would help, but the thing crashes every time, and I have tried this on different machines with different architechtures as well. It always crashes about 2.5 hours into it -- very frustrating. Is there anything else I can do to help diagnose the problem? Chris
You could try "cat - >$HOME/test.ps; env >$HOME/test.txt" as command line instead of kprinter; that way we can see what actually gets delivered to kprinter. Normally i wouldn't expect functional differences to what you get by printing to a file - but who knows. Also it should show the environment in $HOME/test.txt; perhaps one can see something strange in there.
I tried something very similar to that.... I can't remember what it yielded. I will have to do it again, but first I have to find a machine I can install the rc1 version on... I can tell you I tried sending to kwrite instead, and it had a similar effect. I'll have to get back to you on this one... Might be a couple days. Thanks, Chris
Gentlemen, I found the problem. After quite a bit of tinkering it comes down to this: Your soffice script has changed, and this accounts for the difference. If I run soffice.bin straight from the command line, as opposed to soffice, it works just fine. After hacking at the script a bit, I have narrowed it down to a key element: The initial export of the LD_LIBRARY_PATH environmental variable. On lines 112 - 114 in the soffice script, you have a case statement assessing the OS, then exporting this variable with different values depending upon the variable. Since there is no variable for Linux, it uses the *) case. When I dumped the values of sd_progsub and sd_prog I got this: sd_progsub=/opt/OpenOffice.org1.1_rc2/program/local sd_prog=/opt/OpenOffice.org1.1_rc2/program Yielding an LD_LIBRARY_PATH of LD_LIBRARY_PATH=/opt/OpenOffice.org1.1_rc2/program/local:/opt/OpenOffice.org1.1_rc2/program: This is not good, for whatever reason. Normally, my LD_LIBRARY_PATH variable is unset. When I commented out this case statement, my problems disappeared: kprinter works normally. When I put them back in, I get that funky problem. Just for fun, I tried this on the command line: export LD_LIBRARY_PATH="/opt/OpenOffice.org1.1_rc2/program/local:/opt/OpenOffice.org1.1_rc2/program" && echo hi |kprinter Oddly enough, it worked, so there is another variable here unaccounted for. Kprinter itself doesn't care what is in LD_LIBRARY_PATH alone. So OO is doing something in combination with it that kprinter (or any kde app I would guess, since it did the same with kwrite) doesn't like. Maybe kde loses track of its own libs when LD_LIB_PATH is exported in this way... I am not sure. At anyrate commenting those lines from the soffice script did the trick for me. You may want to check that out. Again, this all started with the beta2 release. OO prior to that did not have this problem. The example I used here was OO 1.1 rc2. I hope that this is helpful in further releases of OO. Chris
Strange. I think there are not many customers for LD_LIBRARY_PATH anymore, probably we should eliminate them and the whole soffice script with it.
I'll see if we can get rid of the script.
cp: retargeted to Office-Later due to limited ressources
I was going to submit a new issue, and will try commenting here first - this has gotten MUCH worse in OOo 2 Beta 2. The new OOo 2 includes "libgcc_s.so.1" in its libraries, and this does interfere with the system libgcc_s.so.1 library. Externally called programs should be using the expected system-supplied libgcc_s rather than the one supplied with OpenOffice. Besides being a recipe for incompatibilities with the system libgcc_s, this causes trouble for all systems running with PaX kernels, and on systems that adjust by disabling stack exec protection, it automatically removes that protection on all programs invoked by OpenOffice. We can probably fix locally by hacking the soffice startup script to put the system library directories first in LD_LIBRARY_PATH, but aren't sure of the impact of that on the soffice.bin binary's reliability.
This gets more important since we now have the "external dialog" feature in spadmin. Adjust target.
This is not a problem anymore since the three layer office (at least in 3.2, probably ealier); LD_LIBRARY_PATH now only gets extended to the paths containing the local JRE; meaning that OOo's lib directories do not come up in LD_LIBRARY_PATH anymore.
closing