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.
.imgboxrt{
border:1px dotted #000;
float:right;
margin-left:5px;
margin-right:10px;
}
.imgboxlft{
border:1px dotted #000;
float:left;
margin-left:10px;
margin-right:5px;
}
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.
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 :)
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
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".
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 :-)
Comments
Let me say first: keep up the good work. When I need to do something in an office suite, KOffice is my first choice. Why? Because it's lean and mean and everytime I use it -- which is not frequently, because I do my job almost entirely with TeX -- I'm surprised how much one is actually able to do with it. When do I use OOo? Exactly, when I need a *convertor* from or to MSWord. My thesis is: OOo is so popular because it has decent conversion from and to MSWord. That's great, of course, I couldn't do without it, but it should not make people forget that this does not make it a great office in itself. My biggest wish in KWord is the ability to set the grid (raster in Dutch) to 0pt so that you can position your frames in an absolute way. The move to OASIS is painstaking but good. Note that this means that with TeX4ht, you will have a nice convertor from LaTeX to KOffice/OOo---yes, I came up with that idea, again because basically, it meant LaTeX to Word support.
So, there are users, yes, and they like it very much. My wife wouldn't have an office on her old Pentium I laptop if there was no KOffice. And with OOo, she always had questions, but with KOffice, she doesn't ask anything!
A college of my uses visio a lot and has lots of troubles with it, colors changes, crashes etc. He uses it to create pictures, group them and then drag these to the sencel bar. It then becomes a new stencel, which he then uses as design templates. Otherway around is also possible, take a stencel, drag to document and de-group.
Anyway, that was my experience with this tool :-). But koffice has not such a tool, one has to use two tools and how to make a new stencil is unclear. Wouldn't it make sense to integrate these two?
I use OOo in my law practice, and I like it. I also use KDE as my desktop in SuSE Linux 9.1 Pro, and I like that. I have an interesting little story about how it is important to have both. I am producing a film called the Digital Tipping Point, which is about the cultural implications of the global shift to free libre open source software (FLOSS). In the course of our travels, we have seen much more use of OOo than KDE. So there's an advantage for OOo. However, just the other day, I was downloading my kaddressbook to take with me to the OpenOffice.org Conference in Berlin, and I accidentally clicked on something, maybe it was the CSV file for the addressbook, and BOOM! up comes my data in the Kcalc spreadsheet program! I had previously tried to open the CSV file with OOo, but somehow I must have botched it. After this accident, I learned that I can now use CSV with OOo or Kcalc. So as with most things software libre, it seems that this little story illustrates how cross fertilization can help members of the community. In this case, I am a very simple end user with very limited computer skills, so I really appreciate being able to have a work around for stuff. So thanks to the KDE developers for a great body of code! Christian Einfeldt, 415-351-1300 [email protected]