A Hands-On Review of the Open Source OpenOffice
By: Michael Hall
Friday, October 13, 2000 03:32:53 PM EST
URL: http://www.linuxplanet.com/linuxplanet/previews/2470/1/
Building from the Source
The big news today may be the unveiling of the OpenOffice web site, but lost in the shuffle has been any reporting on exactly what Sun and CollabNet are offering on OpenOffice.org.
Until now.
We grabbed the source code and binaries from the OpenOffice.org site to see what the new and improved, Open Source StarOffice would look like. As you might expect, Sun did more than just release an Open Source product: it also cleaned up the code and made some significant changes to the software.
How significant? StarOffice is still the monolistic, monster program it once was; although it appears to load in a slimmer package, under the hood you're always running all of StarOffice, no matter what appears on the screen. But the look and feel of the product is improved, thanks to some new True Type fonts; and some elements, like email, are still in development.
There's little point in describing how to find the binaries or source, because a hastily-prepared download page currently replaces the old front page of the site thanks to a crippling onslaught of enthusiasts that managed to bring the site down just after launch this morning.
Building OpenOffice from the Source
StarOffice, as everybody knows, is a large program. Building it is relatively simple once all the pieces are in place. We used a Debian 2.2 (Potato) system with a 650 MHz Duron and 160 MB RAM. Debian users should be aware that completing the build successfully requires more than the normal X libraries they may find on their system (as provided by the xlib6g and xlib6g-dev packages: the xlib6g-static package, used to build statically linked binaries is also required or the configure script provided will fail.
General requirements for a build also include JDK 1.2.2 (available from Blackdown.org, a Perl 5 installation, and csh (bash won't work with the script that sets up the build environment). System requirements include 3 GB of free hard drive space, and 128 MB RAM.
The tarball containing the source weighs in at 80 MB, and contains everything you need to begin building the project. Instructions for how to build the complete package are available at http://openoffice.org/build.html. It's possible to build either the entire OpenOffice suite in its current form, or individual componenents such as the word processor or spreadsheet.
The whole package is not trivial to build in terms of time or resources. Once we worked out the issues with the X libraries on our Debian system, we set out to complete an entire build, which is still in progress as we write this, almost four hours later. Following the instructions provided, though, makes the whole thing very simple. Though it's premature to report success, careful reading of the instructions and making sure all the prerequisites are available before beginning make for a smooth process.
Looking at the Binaries
In addition to the source code, the OpenOffice project provided a set of binaries to allow users a chance to see OpenOffice in its current state. We downloaded these expecting to see little more than StarOffice 5.2 with maybe some cosmetic changes, and were pleasantly surprised to find we were wrong, but we'll get to that.
Installing the OpenOffice suite is as simple as it ever was under StarOffice. The installation tarball provides a single installer binary that launches the familiar StarOffice installer program. The main change experienced users will note is the replacement of the StarOffice butterfly with the OpenOffice logo. Once it comes time to select which components to install, there are a few items missing from StarOffice 5.2, including Palm support and the wide variety of languages. The installer remains intelligent about searching out and suggesting a Java installation to use, as well.
Though the installer still seems to allow the /net switch, which permits multiple users to share a single installation of the main program with smaller, personalized directories for file and configuration storage, we had no luck getting this installation to run and decided to resort to the standard installation, which drops the program tree and all the needed files in a single, central directory.
Running OpenOffice
The biggest complaint we had the last time we looked at StarOffice, and often heard from the program's users, was the nature of the interface. StarOffice's "Do everything in one place" philosophy included providing an entire desktop environment with which to access the various components of the suite. This drove up the program's footprint, and made for a sense of clunkiness and wasted screen space. This issue is already addressed on the first day of OpenOffice's release: the StarOffice Desktop is gone.
On launching the program, StarOffice Writer is the only program to present itself. The style wizard still exists as a curious Windows 9x-looking window that's constrained to the boundaries of the word processor's frame, but file dialogs and any additional windows the user chooses to open are under the control of the user's window manager.
We were unable to determine how to open any other app besides the word processor at launch, when we ran the soffice binary. The only way we could find to start a new spreadsheet, illustration, or graph is to select the File/New menu item and select the appropriate file type. Once the new file is created, it opens in its own window, and has no more control buttons than are necessary to the app being used.
Appearances are also deceiving. Those who didn't like the fact that a single, monolithic application is running the show with StarOffice will remain unhappy. Despite the welcome change of getting everything out from under the StarOffice Desktop, the application itself remains a single program, at least according to top. Launching a spreadsheet, a presentation, and other application windows had no effect on the number of processes running, and a minor effect on the memory footprint of the program: its five threads continued to consume about 20 MB of RAM.
Besides the fact StarOffice's components are now run as individually managed windows, users used to StarOffice won't see much difference in the look and feel of OpenOffice. Users familiar with StarOffice will be instantly familiar with the software in its current state.
One addition we did notice rather quickly was a new set of TrueType fonts that came available "out of the box." Font rendering under OpenOffice seems to be much cleaner than it was under StarOffice, where font scaling problems often rendered the text jagged and difficult to read on the screen. We experimented with importing Microsoft Office documents, which went off without a hitch (even a document that repeatedly crashed Applix Words), and we succesfully embedded documents between OpenOffice applications. We weren't able to configure a printer.
Currently missing from the available elements of the suite are the mail and news programs as well as the schedule program. The address book remains, and is tied to the database element of the suite, which is not available on its own. It's not appropriate to speculate about what the current existing elements or the missing pieces from StarOffice 5.2 represent since the composition of the suite is presumably open to the direction the OpenOffice project chooses to take it.
Down the Road
Our look at the Day One incarnation of Open Office is, of necessity, superficial. StarOffice has become an open source project, which means even if Sun is still heavily involved in its management, there's plenty of potential for change from what we got to see today.
Most importantly, the project will be made to work with the GNOME project's Bonobo component model, which means that much of the existing object embedding and file linking present will likely undergo severe change. In addition, the interface will be undergoing profound change as it's converted to something that integrates more tidily with the GNOME desktop environment.
Even though these big changes are coming, and the download/build of the source package is daunting for those with little time or bandwidth, the binaries are worth examining if for no other reason than to remember what the software looked like on its first day as an Open Source project.