OpenOffice.org Resource Files
Most users interact with OpenOffice.org on the desktop. But what if you need to do a selective restore on the files that store custom gradients or colors? Troubleshoot why an extension won't install? Share resources with other users? For these kinds of tasks, you need to know a bit about where OpenOffice.org stores its files, and what you can do with them.
OpenOffice.org's file structure is simple, but it is deceptive. What you see on the desktop (for instance, when you choose a template to base a new file upon) may not be an actual directory, but a virtual one. Just as when you upload photos, the contents of all memory cards in your camera display together instead of separately, so OpenOffice.org displays many of its resources in a single view on the desktop.
Usually, the directories that make up this single view come from your personal files in /home/~/.openoffice.org/3/user, and from public resources installed with OpenOffice.org, most of which are in /usr/lib/openoffice/basis3.2/share. The numbers in the path differ with the OpenOffice.org versions, and the public resources may be installed elsewhere in some distributions, but you can find which are being used in your system by looking at Tools -> Options -> OpenOffice.org -> Paths.
If you choose, you can also edit the path to resources for the current account, adding other directories as you choose. However, the order does matter -- you'll notice that the default paths are set to look at your local resources first.
The content of local directories
The resources in your home directory are divided into sub-directories. Many of these directories store binary files, so you shouldn't try to edit them. However, knowing what belongs where can be useful if you ever need to recover from a corrupt file, or want to share with others.
Some of the sub-directories contain resources for the basic running of OpenOffice.org, such as /database (the default bibliography database), /LastSession (autorecovery after crashes), psprint (printing) and /wordbook (the default dictionary). Mostly, you should have no reason to interact with these directories. However, if you try to edit or view them and run into trouble, you can restore the contents automatically by logging out of the account then logging back in and re-starting OpenOffice.org.
Other folders, such as /store and /temp, are no longer used, and are probably kept for unlikely possibility that you will need them for backward compatibility if you are working with legacy formats. Others may have been added when you installed an extension, which is what Writer Tools does.
If you ignore these directories, the ones that store resources you might want to be aware of are:
- /autocorr: Contains a file with your preferences for AutoCorrection for a particular language, such as acor_en-US.dat
- /autotext: Contains custom AutoText in the file mytexts.bau.
- /backup: Contains backup files if you have configured OpenOffice.org to do backups at Tools -> Options -> Load/Save -> General. These files will have the same formats as the original files.
- /config: Contains files for graphic resources, such as customized arrowheads, cross-hatchings, gradients, and colors. For those who make extensive use of OpenOffice.org's Drawing Tools, this is an essential directory for backing up.
- /gallery: Clipart that displays in a floating panel when you select Tools -> Gallery. If you have a lot of clipart to upload at once, you can save time and avoid tedium by installing everything directly to this directory using a file manager rather than going through OpenOffice.org. The only drawback is that you may need to restart OpenOffice.org before the new material displays in the Gallery.
- /template: Contains the templates that you create.
- /uno_packages: Contains the extensions installed in the current account, as well as a log of what extensions you have installed or removed. Annoyingly, the useful information is buried several directory levels down. Even more annoyingly, extensions are identified not by name, but by an apparently arbitrary code. However, if you drill down to yet another level, you find a directory with the Extension's name.
Some of the files mentioned here are binaries, so you won't be able to read them in most text editors or word processors, including OpenOffice.org Writer.
Local vs. public
From the viewpoint of the current account, whether you put resources in your home directory or the public directory is irrelevant. However, if you want to share a resource, then you need to put it in the public directories -- remembering, of course, to set the permissions so that non-root users can read the files.
Many versions ago, the directories for the local and public versions were nearly identical. However, that is no longer true. Many of the resources in the public directory that are used to create each user account's /.openoffice directory are no longer copied automatically. Nor is there any real need to do so. After all, why have the XML and CSS files needed to display each OpenOffice.org application or the character sets for different languages installed to every account?
However, in at least one case, an overlap can be useful. If you have a font that you need to use in OpenOffice.org, you can create your own font directory in /home/~/.openoffice/3/user, and quickly install it without having to log in as root. In fact, thanks to OpenOffice.org's virtual directory structure, you seem to be able to duplicate locally every sub-directory in the public directory, although so far this is the only practical use I have found for this feature.
Under the hood
An office suite is such a standard tool that you can easily forget that there is more to it than you see on the desktop. However, even a quick check under the hood like this one can make administration tasks easier. Spend some time looking at the resources that help you run OpenOffice.org, and you'll be able to do those tasks just a little bit more easily.
Bruce Byfield (nanday)
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
|Non-Linux FOSS: Seashore||May 10, 2013|
|Trying to Tame the Tablet||May 08, 2013|
- RSS Feeds
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- Validate an E-Mail Address with PHP, the Right Way
- Drupal Is a Framework: Why Everyone Needs to Understand This
- A Topic for Discussion - Open Source Feature-Richness?
- Download the Free Red Hat White Paper "Using an Open Source Framework to Catch the Bad Guy"
- Home, My Backup Data Center
- Tech Tip: Really Simple HTTP Server with Python
- Please correct the URL for Salt Stack's web site
47 min 19 sec ago
- Android is Linux -- why no better inter-operation
3 hours 2 min ago
- Connecting Android device to desktop Linux via USB
3 hours 31 min ago
- Find new cell phone and tablet pc
4 hours 29 min ago
5 hours 58 min ago
- Automatically updating Guest Additions
7 hours 6 min ago
- I like your topic on android
7 hours 53 min ago
- Reply to comment | Linux Journal
8 hours 14 min ago
- This is the easiest tutorial
14 hours 28 min ago
- Ahh, the Koolaid.
20 hours 7 min ago