Interview: Wer braucht KOffice?

Golem.de im Gespräch mit David Faure. Mit KDE 2.0 erblickte auch die auf KDE basierende freie Office-Suite KOffice das Licht der Welt und enthält mittlerweile zahlreiche Einzelapplikationen, die weit über die Standard-Office-Funktionen wie Textverarbeitung und Tabellenkalkulation hinaus gehen. Gemeinsam mit OpenOffice.org hat man zudem unter dem Dach der OASIS ein universelles Dateiformat für Office-Applikationen entwickelt. Im Vorfeld der KDE-Konferenz aKademy sprach Golem.de mit KOffice-Entwickler David Faure, der die Interessen der KOffice-Entwickler auch im technischen Komitee der OASIS vertritt.

24. August 2004 um 11:25 Uhr / Jens Ihlenfeld

Golem.de: In den letzten Jahren wurde KOffice beständig weiterentwickelt und hat neue Software-Komponenten erhalten. Wo sehen Sie KOffice heute und welches waren die wesentlichen Schritte, die KOffice bisher genommen hat?

David Faure: In der Tat sind in der letzten Zeit zahlreiche neue KOffice-Komponenten entwickelt worden: Kexi, die Datenbank-Applikation, ist ein bisschen vergleichbar mit Access und sieht bereits ziemlich gut aus. Bei der Bildbearbeitungs-Software Krita geht die Entwicklung derzeit gut voran. Und auch die Arbeit an der Projekt-Management-Applikation KPlato hat begonnen, hier werden aber noch Entwickler benötigt.

Ich denke, dies ist die Stärke von KOffice im Vergleich zu den Open-Source-Mitbewerbern: Es wurde mit der Qt-Plattform, der KDELibs-Technik und der KOffice-Architektur ein mächtiges Fundament gelegt, um die Entwicklung vieler Office-Komponenten interessant zu machen, was die Anzahl der bereits verfügbaren KOffice-Komponenten belegt.

Als wesentlicher Schritt für KOffice seit der Version 1.1 wurde eine gemeinsame Text-Engine in KWord und KPresenter integriert, die auf Qts "QRichText"-Engine beruht. Diese wird auch in der aktuellen Version 1.3.2 verwendet. Derzeit arbeite ich an der Unterstützung für indische Schrift in unserer Version dieser Text-Engine. Zudem wird die Rechtschreibkorrektur grundlegend überarbeitet und auch am OASIS-Dateiformat sind wir dran.

Golem.de: Welche Teile von KOffice benötigen noch die meiste Arbeit?

Faure: Die Entwicklung einer Office-Suite ist eine riesige Angelegenheit. Jeder Teil verlangt nach viel Arbeit und es ist schwer, einfach den Nutzerwünschen zu folgen, da jeder andere "Must-have"-Funktionen nennt.

Konkret werden wir zunächst die Implementierung des OASIS-Dateiformats fertig stellen und an den Dokumenten-Konvertern arbeiten, so dass sie mit dem OASIS-Format umgehen können. Anschließend werden wir entscheiden, ob wir unsere Text-Engine sowie KWord und KPresenter auf die neue, recht vielversprechend wirkende Text-Engine von Qt4, "Scribe" genannt, umstellen.

Der größte Schwachpunkt an KOffice 1.3 ist die WYSIWYG-Implementierung, aber wir denken, dass sich dies mit Qt4 verbessern könnte. Man hat mir versichert, dass daran gearbeitet wird.

Ein anderer Bereich, in dem hoffentlich etwas passieren wird, ist "Scripting": Es gibt Überlegungen, KJSEmbed für das Scripting in KOffice zu verwenden, die mächtige und flexible Sripting-Engine auf Basis von Konquerors JavaScript-Interpreter (KJS). Abgesehen davon sind es die Applikationen, an denen am meisten getan werden muss: KFormula und KPlato könnten definitiv Unterstützung gebrauchen.

Golem.de: Sie sitzen im technischen Komitee der OASIS, das sich um die Definition eines Standard-Dateiformats für Office-Applikationen bemüht. KOffice unterstützt schon heute das Dateiformat von OpenOffice.org, das auch an die OASIS übergeben wurde. Halten sie das Format für eine gute Basis?

David Faure: Mehr als das – ich habe sichergestellt, dass dieses Format eine gute Basis für KOffice darstellt. Das ist meine Aufgabe im technischen Komitee der OASIS: Sicherstellen, dass sich alles, was KOffice unterstützt, in dem Dateiformat ablegen lässt. Aber ich denke, das OpenOffice.org-Format war sicherlich eine sehr gute Basis für das OASIS-Fomat, schließlich war es von Beginn an auf eine möglichst große Unabhängigkeit vom Applikationsdesign ausgelegt.

Es verwendet so viele bestehende Standards wie möglich, darunter XSL/FO, CSS und HTML. Das OASIS-Format soll letztendlich zu einem weiteren derartigen Format werden, bei dem die verwendete Applikation keine Rolle spielt. Aber realistisch gesehen ist es angesichts der vielen Funktionen in den Office-Applikationen noch ein sehr langer Weg, bis diese in den beiden Office-Suiten OpenOffice.org und KOffice verfügbar sind.

Golem.de: Die größte Herausforderung für Office-Suiten stellt die installierte Basis von Microsoft Office mit vielen vorhandenen Dateien in einem proprietären Format sowie spezielle Software wie Makros für dieses System dar. Wie kann KOffice diese Hürde überwinden?

David Faure: KOffice verfügt über einige Konverter für Microsoft Office, auch wenn diese definitiv verbesserungswürdig sind. Aber in Anbetracht der mangelnden Man-Power auf Seiten von KOffice wird es weder möglich sein, diese Konverter zu 100 Prozent fertig zu stellen, noch Unterstützung für Microsofts VBA-Makros zu implementieren.

Das Zielpublikum von KOffice sind daher eher Leute, die neue Dokumente erstellen, weniger diejenigen, die mit veralteten MS-Office-Dokumenten arbeiten. In jedem Fall ist es gut, das gleiche native Format wie OpenOffice.org zu unterstützen, denn damit lassen sich die Dateien in das OASIS-Format konvertieren, das OpenOffice.org und auch KOffice verarbeiten können. Nicht, dass die Konverter von OpenOffice.org zu 100 Prozent vollständig wären.

Golem.de: Als KOffice mit KDE 2.0 veröffentlicht wurde, gab es keine andere Open-Source-Office-Suite für Linux. Aber mit OpenOffice.org gibt es heute eine Lösung, welche die Anforderungen der meisten erfüllt. Worin liegt der Vorteil von KOffice und warum ist es notwendig, die Entwicklung der Software fortzusetzen, anstatt die Kräfte mit anderen Projekten wie OpenOffice.org zu vereinen?

David Faure: Diese Frage wird mir immer wieder gestellt. Zunächst einmal gibt es einige Nutzer, die KOffice vorziehen – aus Performance-Gründen (Geschwindigkeit und Speicher), wegen der Integration in KDE und auf Grund des benutzerfreundlichen Interface sowie der Vielzahl und Komponenten. OpenOffice.org hat nichts, was Kivio oder Kexi nahe kommt.

KOffice verfügt über eine flexiblere Architektur, das beweist der "KOffice Workspace", in dem sich alle KOffice-Komponenten gemeinsam nutzen lassen, oder die Möglichkeit, KOffice-Dokumente in Konqueror zu betrachten, der die KOffice-KParts direkt einbindet, aber auch die Tatsache, dass die Dokumenten-Konverter von der Kommandozeile über "koconverter" aufgerufen werden können.

Ohne etwas Schlechtes über die Konkurrenz sagen zu wollen – ich habe großen Respekt vor dem OpenOffice.org-Projekt – denke ich, es ist deutlich einfacher, in den Code von KOffice einzusteigen, da dieser deutlich übersichtlicher ist.

Im Unterschied dazu ist es unmöglich, durch den Code der MS-Word-Konverter von OpenOffice.org durchzusteigen, insbesondere für jemanden, der kein Deutsch spricht, denn alle Kommentare sind deutschsprachig. Auch der Build-Prozess und die Internationalisierung von OpenOffice.org haben insbesondere unter Linux-Distributoren einen schlechten Ruf, während KOffice die Standard KDE- bzw. GNU-Mechanismen nutzt. Zudem macht es den Eindruck, als sei es durch Suns Kontrolle schwierig, OpenOffice.org in größerem Umfang zu verändern. Entwickler bei KOffice haben hingegen nahezu alle Freiheiten, zu tun, was sie wollen.

Die Tatsache, dass es zwei konkurrierende Office-Suiten gibt, ist im Großen und Ganzen eine gute Sache: Ohne KOffice würde es so etwas wie das Standard-OASIS-Dateiformat für Office-Dokumente nicht geben. Es gäbe zwar etwas, das als solches bezeichnet würde, aber wie kann etwas ein Standard sein, bevor es nicht von mehr als einer Applikation unterstützt wird? Erst die Anforderungen von zwei Office-Suiten haben es erlaubt, das Format aufzuräumen und weitgehend implementierungsunabhängig zu machen.

Sollte eine andere Office-Suite auf OASIS als natives Dateiformat umsteigen, müsste man es wohl nochmals erweitern. Aber zumindest können wir sagen, es ist bereits generisch genug, um die Anforderungen von zwei Office-Suiten zu erfüllen. Das ist ein guter erster Schritt.

Golem.de: Würden Sie eine bessere Integration von OpenOffice.org in KDE begrüßen?

David Faure: Sicherlich, warum nicht? Es macht KDE-OpenOffice.org-Nutzer froh. Für KOffice-Nutzer ändert sich dadurch nicht viel.