KOffice - Portability in Action

I have on several occasions been asked "why do you work on KOffice when OpenOffice.org already exists and does everything people need?". Well, there are several reasons why OpenOffice.org (OOo) is not the end-all of free office suites. This blog is the first in a series that will outline why KOffice is necessary and why it may in fact be the real future of the free office suites.

Let's start in this blog with portability.

KOffice runs on all Linux distributions which is not surprising since most of it is developed on Linux. It also runs on Windows and MacOS X, although these ports are not production ready yet. There is still some infrastructure and packaging work to do, but the KDE Windows and MacOS X teams are doing a fine job there. These three platforms are also the ones that are supported by OOo.

But it doesn't end there. Three days ago, a KOffice port to Haiku, the free followup of BeOS, was announced. The porting team had started out by porting Qt, the great C++ toolkit from Trolltech, now owned by Nokia. After that they continued with the KDE libraries and then KOffice and most other KDE applications were just a simple matter of compiling. There is also a port of KOffice to FreeBSD, which is another Unix dialect where, to my knowledge, OOo doesn't work. Edit: OOo is available on FreeBSD as shown by one of the comments, my bad.

KOffice on Haiku

But to make things really interesting, we have to look at the mobile devices. This week we saw the first alpha release of the office viewers on the Nokia N900 device. This release is interesting in several ways. First of all, it's not a normal Intel processor and not a normal desktop or laptop machine with all the power and memory that such a machine has access to. Instead it's an embedded device and demands a very low energy consumption but still needs to provide a fast response to the user.

The office viewer on the Nokia N900 with its custom UI.

The other challenge with the N900 port was that the UI had to be switched for a new one. The desktop version of KOffice uses the normal WIMP interface (Windows, Icons, Menus, Pointers) but the N900 device has a touch screen and a small form factor. The desktop UI would simply not be workable for such a device. KOffice is the only free office suite that allows the developer to use the internal engine for loading and rendering the contents and create a custom UI on top of it.

So, what gives KOffice this great flexibility and portability? Well, first of all it's the Qt toolkit. Qt is arguably the most portable toolkit of all, and especially if you take into account that it provides a native look&feel on all platforms that it is ported to. Qt is ported to all Unix dialects, Windows, Mac, Symbian and many more. On X windows it can even take on the look of the desktop environment, like Gnome or KDE Plasma.

Second, it's the design of KOffice itself. KOffice has a very modular design. Not only is the GUI mostly separated from the engine, it's also very much based on plugins. In some cases even plugins have plugins -- the spell checker, for instance, is a plugin to the text shape, which is a plugin in itself.

The first point makes it possible for the developer to create completely new UI like Nokia did. We foresee KOffice ported to Symbian and other mobile OS'es like Moblin and Android once Google allows native applications that are not written in Java on it. And why not a port to Windows Mobile?

The modular design with plugins makes it very simple to create a tailored version of KOffice with a selected set of features. Right now, there is a CMake option to the configuration phase called "TINY" that creates a smaller KOffice with a limited set of applications and a limited set of filters and built-in shapes. As far as I know, there is no similar build time options to OOo or Abiword. It's also easy to replace functionality by simply switching a plugin to something similar. An example of this is how Thomas Zander created a simplified text formatting docker for kids with fewer options and bigger buttons.

So, the combination of these two makes KOffice uniquely suited for non-standard platforms. Non-standard by desktop standards, that is. Most people today agree that mobile is the future. And maybe so is KOffice...

KOffice and Embedded Objects Part 1

This is the first blog in a series of two. In this part I will explain how embedded objects are stored in the OpenDocument Format (ODF) and some progress that has been made in KOffice lately. In part 2 I will show what the future has in store.

Now, as you know, any decent office software can handle embedded objects. Such objects can be widely different, from the very simple to the complex. It is the more complex types that I am going to talk about here like charts, music scores or even complete embedded documents.

Here is KWord showing an example document with two embedded objects: a rectangle and a chart:


Let's look at how this is saved inside the odt (OpenDocument Text) file. An .odt file is just a zip archive, and can be unpacked with the normal unzip command:

# unzip ../kword-embedded-objects.odt
Archive: ../kword-embedded-objects.odt
extracting: mimetype
inflating: settings.xml
inflating: content.xml
inflating: styles.xml
inflating: Object_1/content.xml
inflating: Object_1/styles.xml
inflating: meta.xml
inflating: Thumbnails/thumbnail.png
inflating: META-INF/manifest.xml

We have 2 interesting things to look at here: content.xml that contains the document contents, and Object_1 that is a subdirectory that contains an embedded object. Let us start with looking at a part of content.xml. Note that I have applied some formatting on the XML to make it easier to read.

<text:p text:style-name="P1">abc</text:p>
<text:p text:style-name="P2">
<draw:rect draw:style-name="gr1" draw:id="shape1" svg:width="21.36217608452pt" svg:height="31.96877753470pt" svg:y="-31.9688pt" text:anchor-type="as-char"/>
</text:p>
<text:p text:style-name="P2">def</text:p>
<text:p text:style-name="P2">
<draw:frame draw:style-name="gr2" draw:id="shape2" svg:width="226.33462363427pt" svg:height="141.45913977142pt"
svg:x="-57.00000000000pt" svg:y="-42.00000000000pt" text:anchor-type="as-char">
<draw:object xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad" xlink:href="./Object_1"/>
</draw:frame>
</text:p>
<text:p text:style-name="P2">xyz</text:p>

Notice the difference between the two objects, the rectangle and the chart. The rectangle is completely defined inline while the chart is only defined as a frame with a pointer to the actual contents, which is the xlink:href within the draw:object. Right now we can leave the actual contents of the files inside Object_1. That is not relevant here.

The interesting thing in the OpenDocument specification is that you can have more than one object inside the draw:frame element. These objects can be of any of these types:

• Text boxes
• Objects represented either in the OpenDocument format or in a object specific binary format
• Images
• Applets
• Plug-ins
• Floating frames

If you do have more than one object, they are not shown next to each other or above each other. Instead the first one that the program recognizes is shown. The rest are just hidden from the user. This is often used by combining a complex object and a picture that shows the same object. The idea is that even if the application can't handle the complex object, then at least it can show the picture to the user. These pictures are often called Object Replacements since that name is used by OpenOffice.org as the name for the directory in the ODF file where the pictures are kept.

KOffice has been able to handle such object replacements for a long time. However all the formats that KOffice could handle were bitmap formats. Bitmaps are good because they are easy to handle, but they are bad because they don't scale well. They become grainy or blocky when they are scaled up and you lose precision.

When you are dealing with MS formats like DOC (MS Word) or PPT (MS Powerpoint), you will find that the same concept of Object Replacements exist there. Naturally MS use their own formats, and in this case the formats in question are WMF (Windows MetaFile) and EMF (Extended MetaFile). WMF is an older 16 bit format and EMF is the newer 32 bit format. Both are vector formats so they are easy to scale and will not lose precision.

I have worked on import of embedded objects a while now and specifically to be able to import and show WMF and EMF. Except for one bug that I know of, I am now done: KOffice can now show embedded objects with object replacements using either WMF or EMF. To import and convert all of the MS file formats is a very big task and I'm sure that in the long run the KOffice team will manage that as well. But already now the users will be able to view any embedded object provided that there is a suitable object replacement. This will be available from KOffice 2.2.

As a proof, I give you this screenshot of KWord compiled from trunk that imports a DOC file with an embedded chart (the bug I was talking about is the text displacement in the legend):


KOffice 2.2 is shaping up very nicely. But it will be even better than this, and that is the topic of part 2 of this series.

Edit: the bug is now fixed.