Just a few (rambling) thoughts on OpenOffice I've been having as of late. My daughter just started Kindergarten and my wife is now caught up in the PTA. So unlike the tech world, which tends to revolve around excel spreadsheets, the PTA revolves around word documents. My wife is relegated to using OOo. So far there have been no compatibility issues.

Calendars and OOo...

So instead of using something sensible like google calendar to create a PTA/School calendar that multiple people can edit (and actually do useful stuff with), the calendar is hand made in word. (Not necessarily hard, but painful, and very annoying for us automate the world freaks to watch being created. Plus you miss dates like the 31st. ~~Sadly, no templates are available for OOo and calendars.~~(see http://www.ooomacros.org/user.php#217442 ) I'm half tempted to rip apart the OOo doc and create an ical2odt.py But that would require people starting with a tool that generates ical...)

10 minutes with Symphony

I've heard about IBM's looming office application for some time, hearing that it was a thick client based on eclipse, with support for ODT. Well, when the beta1 came out last month I took it for a spin. The screenshots made me think that they had reverted to VisualAge technology....(it actually looks much better on linux) The download was pretty hefty at 220M, but the install was smooth. A minute or so after startup, I was able to create a doc. The view looked very much like OOo. So I started looking around it appears that they embed an instance of OOo (soffice.bin) as well as starting the java framework for the controller. All in all the experience was sluggish and appears to eat memory. I was hoping for an implementation in pure java/swt, but I was wrong. As such, I see no current reason to use Symphony instead of OOo. I'm not willing to learn a new gui, just to use more memory and end up with the same functionality. As an added bonus, it doesn't kill the soffice.bin instance when I quit!

KOffice

I've talked about OOo and KOffice before, and recently slashdot has too. Although web based processors are becoming more popular, I think anything more heavy than wiki editing is still best done on a thick client. (Note I'm not anti-AJAX, quite the opposite, as I've been playing around a bit (read full-time) with YUI and DOJO recently). So this is a prime area for KOffice to become the "firefox of word processors". And Windows/Mac compatibility is necessary to help in that effort (unless you believe the prime purpose of KDE is helping/forcing others to adopt Linux (which I've come to believe is a futile fight)). If KOffice can give 90% of people the features they need, thats a win for the ODT format. I'd use a snappier ODT client in a minute for most of my OOo stuff.

3 Some good bloat

But OOo is actually really powerful there are features lurking under that bloat that just might come in useful (about once every 3 years or so). I found out about the form creation the other day. If you export as PDF, then the form will be editable in pdf! Cool, and somewhat useful depending on who you and your audience are.

So what to do?

Since my preferred lightweight markup these days is rST, I was thrilled to see this rst2odf converter. While I'm enjoying rst2s5 I keep thinking that sometimes an rst2impress or rst2prosper could be very useful at times. Or now that I'm fiddling with dojo, a rst2dojopreso, and perhaps integrate my pygments svg output....

Ok, that's enough rambling, just note that most of the power of OOo is in the format standardization. It allows one to create ancillary applications and scripts easily. It permits us to sleep easily at night knowing that we will be able to access our data in the future.