A few weeks ago KOffice 1.3.3 was released, the third bugfix release in the 1.3.x series. The people of Golem.de conducted an interview with David Faure, maintainer of KWord and the KOffice libraries about KOffice. They have sent us the English version for publication on the KDE news website for your reading pleasure.
border:1px dotted #000;
border:1px dotted #000;
KOffice has evolved over the last years. New software components were
added. Where do you see KOffice today and what are the main steps
KOffice has taken?
New KOffice components have indeed been developed recently:
Kexi, the database application (somewhat similar to Access) is looking
quite good already, and Krita (bitmap image editing) is under heavy development. The start of a project-management application (KPlato) needs more developers
I think this is the strength of KOffice compared to its open-source "competition":
having developed a solid enough foundation (Qt "platform", kdelibs technologies,
and koffice architecture) to make it appealing to develop many office-suite components,
as proved by the number of KOffice components existing already.
The main step taken by KOffice since 1.1 has been to implement a common
text engine for KWord and KPresenter based on Qt's "QRichText" engine.
This is used up to the recent 1.3.2 release. I'm currently working on support
for the Indic scripts in our version of that text engine.
Since then, the work has been on reworking spell-checking completely,
and the OASIS file format which we'll talk about later on.
Which parts of KOffice still require the most work?
An office suite is a huge thing to develop. Work is needed in almost every
part of it, and it's hard to simply follow users's demands as everyone's
"must have" feature is a different one.
More specifically, I can see that the immediate future is going to be: finishing
the OASIS file format implementation and working on the document converters
to make them use the OASIS format, then looking at whether to rewrite our
text engine (as well as KWord and KPresenter) to be based on Qt4's new
text engine (dubbed "Scribe"), which looks very promising.
The main flaw in KOffice-1.3 is the WYSIWYG implementation, and the idea is
that Qt4 will solve that problem (I've been assured that work is happening
Another area where work is hopefully going to happen is scripting: there are
talks about using KJSEmbed, the powerful and flexible scripting engine based
But apart from that, entire applications require the most work: KFormula,
and KPlato, could definitely do with some new developers :)
You are working in the OASIS technical committee on the definition of
a standard file format for office suites. KOffice supports the file
format from OpenOffice.org that has been submitted to OASIS. Do you
consider this format a good base?
More than that, I made sure that this format would be a good base for KOffice :)
That's what my job in the OASIS technical committee is: ensuring that the
file format can be used to express everything that KOffice supports.
But I definitely think the OpenOffice.org file format was a very good basis
for the OASIS format, since it was designed, from the start, as a file format
that should be as independent as possible from the design of the application.
It reuses standards like XSL/FO, CSS, HTML etc. as much as possible, so
the goal is to make the OASIS format another one of those formats, where
the application used to edit the document doesn't matter. Realistically though,
given the amount of features available in office suites, it is going to be
long way until all features are available in both office suites implementing
that file format (OpenOffice.org and KOffice, for the moment).
The biggest problem for office suites is the installed base of
Microsoft Office with lots of files in proprietary formats and
special software like macros for this system. How could KOffice
overcome this problem?
KOffice has some Microsoft Office document converters, although those
could definitely use more work as well. But given the lack of manpower in
KOffice, I don't think anyone is going to be able to make those converters
100% complete, nor implement support for Microsoft's VBA macros.
The target audience of KOffice seems to be mostly people creating new
documents, rather than people trying to work on legacy MS Office documents :)
In any case, the good thing about sharing the same native format as OpenOffice.org
is that people will be able to use OpenOffice.org to transform their MSOffice
documents into OASIS documents, editable by both OOo and KOffice :)
Not that OOo's converters are 100% complete either, of course...
When KOffice was released with KDE 2.0 there was no other open source
office suite for linux. But especially with OpenOffice.org there is
free solution that fits most peoples needs. What's the advantage of
KOffice and why is it nessecary to continue the development of this
software instead of joining forces with other projects like
I get this question all the time, obviously :)
First, a number of users have assured us that they prefer KOffice.
For performance reasons (speed and memory), for its integration with KDE,
for its user-friendly user interface, and for its wider variety of components
(OpenOffice.org doesn't even have an equivalent of Kivio or Kexi).
KOffice also has a more flexible architecture, as proven by the
"KOffice Workspace" application which allows to use all KOffice components
together, by the possibility to view KOffice documents in Konqueror
(which also uses the KOffice KParts components directly), or by the fact that
its document converters are available from the command-line using "koconverter".
Without wanting to say bad things about the competition - I have much respect
for the OpenOffice.org project - I also feel that KOffice's codebase is much
easier to get into, and somewhat more cleaner. The code for the MS Word converter
in OpenOffice.org is impossible to get into, especially for a non-german speaker
(all the comments are in German!). The build process and the internationalization
process of OpenOffice.org also have bad reputation (especially with linux distributors),
whereas KOffice uses the standard KDE (in fact gnu) mechanisms. It also seems
Sun's control makes is difficult to change OOo too much, whereas developers
are (almost) completely free to do what they want when working on KOffice :)
The presence of two competing office suites is also a good thing in the
grand scheme of things: if KOffice didn't exist, there would be no such thing as a
"standard" OASIS file format for office suite documents. There would be something
called as such, but how can something really be a "standard" until it's used by
more than one application? Looking at the needs of two office suites is what
really made it possible to clean up the file format and make it somewhat
implementation-independent. Of course if any other office suite wanted to switch
to OASIS as the native file format we might have to extend the format some more,
but at least we can say it's generic enough to fit two office suites already,
that's a good first step.
Would you welcome a better integration of OpenOffice.org in KDE?
Sure, why not. It makes OpenOffice.org KDE users happy.
Doesn't change much for KOffice users though :-)