I’d been having issues with colors in OpenOffice.org applications while using a dark GTK2.0 theme for my Gnome environment. OpenOffice.org applications would start in a high contrast mode and would not display the pages with correct coloring. What you would see on the screen could be far different from what you print. Apparently this is a known bug at OpenOffice’s bug tracker, but there’s yet to be a fix. One commenter posts that it still persists in the 3.0 Beta.

The Ubuntu forums had this asked and answered with a workaround, but that broke with the new release of 8.04 Hardy Heron. I couldn’t find an updated workaround and between desperation, aggravation, and a lack of patience, motivation set in and I went about to find one of my own.

Short Overview

First a short lesson. The shell scripts that run all of OO.o’s applications are found in the following directory:

/usr/lib/openoffice/program/

Each of the OO.o applications has its own shell script.

  • swriter – OpenOffice.org Word Processor
  • scalc – OpenOffice.org Spreadsheet
  • sbase – OpenOffice.org Database
  • simpress – OpenOffice.org Presentation
  • smath – OpenOffice.org Math
  • sdraw – OpenOffice.org Drawing

Each of these executes one main shell script, soffice, while passing it an argument that defines what application you’re planning on using. It’s this file we’ll be using in our workaround

In order to tell OO.o what theme to use, we set an environment variable pointing to the gtkrc file of that theme while we execute the script for that program. For instance, the following launches OpenOffice.org Word Processor with Ubuntu’s Human them:

sudo env GTK2_RC_FILES=/usr/share/themes/Human/gtk-2.0/gtkrc /usr/lib/openoffice/program/swriter

Two flaws with this is 1) because you need to use root privileges to set environment variables, you inadvertently run OO.o applications with root privileges as well, and 2) it’s a hassle to have to do this manually. You could edit each of the OO.o shell scripts and include the above environment variables.

#!/bin/sh

cmd=’dirname “$0″‘/soffice
exec “$cmd” -writer “$@”

…would become…

#!/bin/sh

cmd=’dirname “$0″‘/soffice
exec env GTK2_RC_FILES=/usr/share/themes/Human/gtk-2.0/gtkrc “$cmd” -writer “$@”

But that would be a hassle to change them all back if you change your mind in the future. I thought it best to edit just one.

Workaround

The directions that follow assume that you are running Ubuntu 8.04 with OpenOffice.org 2.4.x installed. The same workaround should work with other distributions as long as directory locations are corrected to match your specific operating system. As donoterase has commented below, his OO.o installation directory is different.

Step 1:

First thing I did was rename the soffice file. Open a terminal and at the command line and just move it.

sudo mv /usr/lib/openoffice/program/soffice /usr/lib/openoffice/program/soffice1

Step 2:

Now, make a new soffice file.

sudo gedit /usr/lib/openoffice/program/soffice

Step 3:

Paste the following shell script code and save the file.

#!/bin/sh
env GTK2_RC_FILES=/usr/share/themes/Human/gtk-2.0/gtkrc /usr/lib/openoffice/program/soffice1 “$@”

Step 4:

Next, make it executable.

sudo chmod +x /usr/lib/openoffice/program/soffice

Step 5a:

There are two options for step 5. The quick and easy way is to rename the binary file. The original soffice script sets a basename variable for the binary’s file name based on the script’s file name. Since we renamed the script to soffice1, we need to rename the binary to soffice1.bin. Braver souls can opt for Step 5b.

sudo mv /usr/lib/openoffice/program/soffice.bin /usr/lib/openoffice/program/soffice1.bin

Step 5b:

If you’re comfortable enough, you can edit the line in the original soffice file instead of renaming the binary. While Step 5a works, I’d rather keep the binary name as is just in case there’s a dependency for it which I haven’t come across. Find the following line of code in your now soffice1 file:

sd_binary=’basename “$0″‘”.bin”

Comment that out and add a similar line below and save it.

# sd_binary=’basename “$0″‘”.bin”
sd_binary=”soffice.bin”

Conclusion

Now, each and every OpenOffice.org app should launch using the Ubuntu Human theme to display the correct layout coloring. I had mixed results when using other themes. Some worked well while others didn’t work at all. The dark theme that I’m using, Overglossed by TheRob, gives me dark-blue panel colors with some themed areas, but high contrast icons. Layout color was incorrect. Slickness-Black, also by TheRob, forces OO.o applications into their default high contrast mode. For myself, I’ll stick with the Human theme so I can enjoy the graphs in my spreadsheets the way they were intended.

Now, this assumes that nothing about your OpenOffice.org installation will change any time soon. This workaround could very well break with a future update to OpenOffice.org. It would be very likely to break between Hardy Heron and Intrepid Ibex. But that’s why we call this a workaround and not a fix.

Keep in mind as with any fixes or workarounds, you do so at your own risk. However, if something needs clarifying, don’t hesitate to ask.

OpenOffice.org 3.0.0

If you were successful with installing OO.o 3.0.0 and would like to apply the above to it, just replace /usr/lib/openoffice/program in the instructions above with /opt/openoffice.org3/program which is default non-Ubuntu installation directory for OO.o 3.0.0.

Share