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 though.

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.

Kword

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 towards this).

Another area where work is hopefully going to happen is scripting: there are talks about using KJSEmbed, the powerful and flexible scripting engine based on KJS (konqueror's javascript interpreter), for scripting in KOffice. But apart from that, entire applications require the most work: KFormula, and KPlato, could definitely do with some new developers :)

Karbon14

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).

Kivio

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...

KPresenter

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 OpenOffice.org?

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".

Kexi

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.

Krita

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 :-)

<  |  >