Quite a few KOffice developers took the opportunity to meet during the Kastle event in Nové Hrady, and particularly to discuss the future ofKOffice after the next major release (KOffice 1.3 slated for the end of September 2003). A summary of the topics discussed follows.

Topics discussed
File format
We will switch to the OASIS
(OpenOffice.org) file format for all the major applications. This has many advantages:

file format shared with the OpenOffice.org suite, we don't have to
reinvent the wheel

we'll be able to drop our OOo import filters and use the export filters
as a compatibility layer for older KOffice versions documents

we can actively participate in the standard file format creation in the
the case of Kexi and Kugar which are applications that don't currently
exist in OOo

This is also a good opportunity to switch the names of our MIME types to the
vnd.kde... naming scheme and to drop our KOffice-specific file
extensions. It's again the users who will benefit from this step, e.g. on
Windows it will be possible to open files created with a KOffice application
using the OpenOffice.org suite.

KOffice libraries
We intend to break the binary compatibility soon after the 1.3 release and take
this opportunity to clean up and refactor kofficecore and
kofficeui libraries.

The next KOffice version will depend on Qt 4.0 which will have a better rich text engine
that we will reuse. Our text library (kotext) will be redesigned as
a thin wrapper around this rich text engine and will provide KOffice-specific
functionality only. (David)

The scripting library (koscript), currently used inKSpread
only, will be rewritten from scratch to provide a new light-weight formula parser.
(Werner, Ariya Hidayat)

Kexi
It is still unknown whether Kexi
will be released separately later this year. Otherwise it will definitely
be part of the next KOffice version. The problem is that Kexi's core API
isn't stable enough yet so it makes no sense to do a separate Kexi release
which would depend on already obsolete KOffice libraries. (Lucijan)

Scripting, automation
We decided to use kjsembed
engine as a foundation for the new KOffice internal
scripting engine. It will allow users to write their own wizards, interactive
forms or scripts using JavaScript and Qt designer forms. Work is also being
done on KDevelop side which will provide an IDE these tasks. (Zack)

Spellchecking
Current plans are either to rewrite the current API after KOffice 1.3 and KDE
3.2 releases or to reuse the newly born Enchant
backend neutral spell checking engine. This architecture will have 3 layers:
different backends, a core library and dialogs. (Zack, Laurent Montel)

Common canvas library
The plan is to have a common canvas class that KOffice applications could
reuse for their own drawing needs. Currently there exist different
implementations inKarbon14,KPresenter andKSvg.
The goal is to have a common library so that also other applications
can draw various shapes without the overhead of KParts embedding.
(Rob, Lukas, David)

Ongoing work
The KOffice developers are currently busy fixing various issues so that we
can ship a stable release candidate at the end of this month.

fix spell checking (Zack, David)

checking that language property is being used for different portions of
text (David)

fix the character (font) dialog in KWord and KPresenter (David, Lukas)

It would certainly be possible to write an equivalent for python, but I have no intention of making kjsembed itself language independent. I think the disadvantages of having a mixture of languages used by different scripts out weighs the pretty minimal gain of supporting more than one. After all, once you support python, why not perl, ruby, scheme etc.

Ian Geiser is working on DCOP support for kjsembed, I'm not 100% sure how much is working right now.

the dcop command is getting through but something is going wrong communicating variant types. lastly i have started on adding the ability to create dcop interfaces in a kjs script but this code needs to be rethought.

I'm very interested in this to see how it may be useful for Kommander, which provides language neutral dialogs with optional scripting. I do my best to follow it, but if you could keep me advised that would be great. As much as I think KJSEmbed is great and a generally good choice for this I think that being able to shell out from an app and run Kommander with DCOP and the option of using any scripting language is worth having too.

Yes, python scripts in KOffice are possible. I already have a "Prove-Of-Concept" plugin for KSpread on my hard disc, but it is outdated and doesn't work with 1.3. Maybe I will look into this again, once I get back to develop on KSpread in mid of September.

I think you're just running up against one of the many python advocates. Python seems to be very popular amongst KDE users and as far as many are concerned, if it only had python they'd be pretty happy. Eric Laffoon has had a lot of discussions on the dot about this and his competing vision about scriptability.

Note that I'm a big fan of python too. It's my favorite language, too. But I do appreciate the work you are doing on kjsembed.

I like python too, but i don't think it's the right language to use here. It is a lot larger than KJS and much more complex. It would be slower to load, add considerable memory overhead etc. (bear in mind that most apps already have kjs in memory through kdeinit). It is also harder to lock python down for security (and no bastion is not good enough for this).

> I think you're just running up against one of the many python advocates. Python seems to be very popular amongst KDE users and as far as many are concerned, if it only had python they'd be pretty happy. Eric Laffoon has had a lot of discussions on the dot about this and his competing vision about scriptability.

And please, if you're going to mention me at least through in a few words about what I'm saying. I don't use Python personally. I also don't think my vision competes per se with Rich's. I like to think they are more complementary in application, but I do believe that the greatest level of user support is achieved by a language neutral approach. It will see the widest acceptance and least complaining about languages. It will not however have all the inherent power of KJSEmbed.

The bottom line is that people don't usually want to learn another language to do something when they are proficient in a different one they prefer. This means some people will avoid using these extentions, and not just the zealots. If you think about it, it's not difficult to imagine having to use a handful of scripting languages with a number of applications. Whatever the benefits of a particular language are it is difficult to outweigh user resistance and saturation of frustration.

FWIW I happen to like Javascript, I think KJSEMbed is cool and I salute Rich in his work. ;-) I'm also working on Kommander as a language neutral solution because I believe it has a somewhat different target audience. (Plus we've had it for some time now.) Choice is good.

It has the very nice feature of a prototype-based object system, which IMHO is much easier to understand than the class-based object system that is used by all other popular programming languages. It is also the only mainstream scripting-level language which uses a C-like syntax, which is quite nice for many programmers (but unfortunately reduces its mainstream-appeal a little bit).

I'm not so happy to hear this. As someone who has done his share of import filter implementation, I've learned that the file format reflects the features of a program. If koffice adopts the OO-format, I'm afraid it might set an upper limit to what features will be possible to implement in koffice. koffice will never be able to go beyond what OO provides, featurewise (at least when it comes to features that require support from the file format).

The two main problems with doing import filters are:
1. The importing program lacks features the exporting program has.
2. The features match, but are implemented differently (the file format often reflects the implementation details).

1 can't be solved, unless the missing features are implemented.
2 can often be solved, but it is often trickier than expected.

To those who claim XML solves the problem by being extensible: If the file format is extended to let koffice implement features not present in the original OO-format, both problem 1 and problem 2 above will show up, and you have gained nothing by using the OO-format. (One of the formats I wrote filters for actually was an XML-format, and I had both problems.)

My suggestion: Keep the koffice format, or change it to suit your needs, but don't depend on others. Make sure everything is properly documented, and write the necessary filters.

I'm afraid the whole file format mess will persist. The problem is not that each program has its own format (that's the way it should be IMHO), but rather that users distribute files in formats that were intended to be used when writing the document. They should instead distribute the files in a format that was created for distribution purposes (e.g. pdf, html, rtf). I realise that this is not always possible since there doesn't exist that kind of format for every application domain.

"They should instead distribute the files in a format that was created for distribution purposes (e.g. pdf, html, rtf). I realise that this is not always possible since there doesn't exist that kind of format for every application domain."

Hello Magnus!

The problem is that in the real world, users can't possibly always do this. My entire office has years and years of (perhaps gigabytes) of MS Word proposals, hundreds of PowerPoint presentations, and a great deal of MS Excel spreadsheets. There are also a lot of very old WordPerfect documents, but those are from the earlier 90's.

We have a enormous investment in MS Office, and currently, 100% of the office machines have MS Office loaded in them. When people in our office need to take home, 99% of the time, it's not a problem because they have MS Office at home.

The problem is for the other (growing) 1%, like me. It's a huge barrier to switching to some alternative OS like Linux without having compatability with existing documents, and being able to effectively communicate with others (which means, the ability to export MS Office docs is important too)

In fact, I was pretty much a hobbist with Linux until OpenOffice came along. Since then, I've been able to switch to Linux full time at home. I've also been using Koffice for years, and I love it's interface compared to OO's crappy interface, but I couldn't really use it for anything serious. And I still can't until there is a way to natively open MS documents (wether it be through OpenOffice, I don't care..)

To me, Koffice doesn't really need to have any more features than OpenOffice.. it just needs to provide a better interface than the crappy java OpenOffice interface.

"The problem is for the other (growing) 1%, like me. It's a huge barrier to switching to some alternative OS like Linux without having compatability with existing documents, and being able to effectively communicate with others (which means, the ability to export MS Office docs is important too)"

I agree with pretty much everything you say, but IMHO the solution is not koffice swithing to the OO-format, but rather work on the import/export filters.

I don't think it's wrong if they base the koffice format upon the OO one, but if they restrict themselves from extending and/or modifying it to suit their needs, they're making a mistake IMO.

(Disclaimer: I haven't looked at either file format, but AFAIK they're both based on XML. I have, however, done similar work in another application domain.)

If we have decided to change our file formats, it is because we do not want to keep the old ones.

So I find that it is better to take a good foundation like the OO format and to build on it, instead of creating again private file formats. Sure private extensions (not necessarily from KOffice) will surely exist, they exist too in RTF. But even in such a document, you can read most of it (instead of nothing.)

As you have written, using XML does not give the solution by itself. Yes, Abiword's file format is not KWord's is not OOWriter's. That is exactly our problem. That is why we try to find a solution.

KOffice just cannot remain an isolated solution, not even (or barely) available on Windows.

Document the file formats? Writing filters. especially for other applications? Nice, but where do you get the manpower? Someone in AbiWord's bugzilla (#1144) asked if a KOffice developer could help with their KWord filters. What can we answer for now? Only: "no, sorry, no people!" (I have not even dared to give this answer yet.)

"So I find that it is better to take a good foundation like the OO format and to build on it, instead of creating again private file formats. Sure private extensions (not necessarily from KOffice) will surely exist, they exist too in RTF. But even in such a document, you can read most of it (instead of nothing.)"

From the article I got the impression that you wanted to use the OO format as it is, not as a base. If you are not happy with the current format and want to switch anyway, and don't mind adding to the OO format, I agree that you should change.

I probably will at some point, but it will (likely) not be file format related work I volunteer (I've done enough to know that I don't like it :-). Until I find the time needed to actually contribute, I lurk on the mailinglists and share my thoughts on things I've some experience with and hope that it will be useful to someone.

In fact we plan to switch to the OASIS format, which is based on OO. As long as David Faure is part of OASIS, it is better to try to make any extension part of OASIS. That is why I suppose that nobody is talking about private extensions.

Thank you to have thought about contributing! If you know so much about file formats, perhaps you could help use with the filter pages ( http://www.koffice.org/filters .) You would need to know about XHTML 1.0, PHP 4 and perhaps XSLT 1.0. So perhaps you could use your knowledge.

Based on what I've read, OASIS is NOT "the OpenOffice" format. OASIS is an independant organization dedicated to creating an open file standard for commonly used business applications. It just happens that OpenOffice.org adopted it first. But I don't think that necessarily places any restrictions on what KOffice will or will not be able to do with the formats. What it does is levels the playing field and places emphasis on chosing, say, a word processor based on what it will do for the user, rather than having to worry about who will be able to read the file type, an idea I'm totally in favor of. This could be the one thing that helps to break the office suite monopoly that Microsoft has such a strangle-hold on. Just remember that in the audio world, the MP3 file type has been embraced completely; no one complains about limitations, and everyone uses which ever recording or playback application they choose. The result is an audio file that can be played back on just about any kind of software or hardware available. I firmly believe the same will happen with office documents with the adoption of the OASIS standard.

And that will put KOffice in a decided advantage over OpenOffice, which is huge and relies too heavily on Java.

I'm wondering what is the status of the new import / export MsWord library that Werner Trobin is working on ?
Importing seems to work already quite well but is exporting still a distant dream or can we expect at least basic exporting in a non-too-distant future ?

Well, I dropped the idea of creating the export code. One reason is that it's just an insane amount of work and I'm only one person with a very limited amount of time. The second reason is, that it's possible to express 100% (yes, really 100%, just read the RTF spec on MSDN) of the MS Word features using RTF. Due to that I'd rather help with RTF export than waste my time on direct .doc export.

If the RTF export filter is going to be the future path for exporting to MSWord. Could KOffice developers implement the 'Abiword trick' : id est having a .doc exporting filter whih is a rtf file with a .doc extension. I guess, it is rather easy to code and will make life easier to users that don't know what is RTF (or Rich Text Format)and don't want to know.

Focusing on the RTF export filter is definitely the best option. (Power)-users can much more easily create test cases, look the exported rtf code, try to understand where it went wrong and help the developers. Something you can't do as easily with the binary .doc format.

Microsoft Wordpad does not export Binary .DOC either, it only exports RTF renamed to .doc

I also recally Wordperfect and Microsoft using the .doc file extension fairly arbitrarily for various formats including Text and RTF.
There are so many version of DOC anyway that quite quickly you need a riguorous file detection algorithm.

While I am here cheerleading for Abiword I may as well mention that it would be really great if KDE users could take a look at making Abiword blend in better with KDE, I am reliably informed that Abiword follows the freedesktop.org icon specification and should be able to use KDE icons when run in KDE.

You can embed an ole stream in a RTF file, for example a Excel datasheet in a Word document with the \object tag.

IMHO, embedding one application into another in MSOffice or KOffice is a nice technological trick but is a recipe for ugly looking printed documents because the two applications use different typographical engines, or different fonts. It is also a hog on ressources on a slow computer. It is much more useful, to have intelligent cut&paste for example a wizard to transform a KSpread table in a KWord table.

This is all very well until you want to edit the embeded object. For example, making an invoice: I want the spreadsheet for doing all the formulaeic work and the word processor for putting some nice headers and footer and any covering text in. And then I want that to be a template so I can use it again. As far as I can tell, intelligent cut and paste just won't cope with that sort of job.

Obviously the option to intelligently remark the is nice to have available but I don't think that should preclude the addition of an embedded facility.

Well, RTF-export is nice. However, there don't seem to be many people around understabnding that code. I tried sending different people code to let the rtf-filter handle tables with only 1 line needing to be changed... I got the answer that nobody had the time/knowledge so that tables will be disabled in rtf-export for 1.3.
I hope that changes some time in the future.

Well, you can see the need in two ways:
- KDE 4.0 will need a KOffice version, so why not a new one.
- the new Koffice version will need time to be done (for example file format switching) and could improve due to Qt4 (for example in KoText, the text engine.)

A little wrong here though. I think Gnumeric beats OOo calc anyday. It is really quite amazing. I do wich they could use the same file format though. That way, they could probably cooperate to use the same export filters too.

What does it mean that you have to "deal with Microsoft Office (MSO) files"? Does this mean that you have to be able to open them in an application so that you can edit them, or does it mean that you just have to read them somehow?

This is an important distinction. Does this "you" really need import filters or just a way to view the file? It would appear to me that it would be MUCH simpler to make (or reverse engineer the MS one) a file viewer than to make an import filter.

And the printer example is even dumber. Hasn't he heard of PDF. Which also means that you don' have to ask somebody to send you a "weirdo-0.00001%marketshare.xxx format???" file, you need to ask them to please send you a PDF.

> And the printer example is even dumber. Hasn't he heard of PDF. Which also means that you don' have to ask somebody to send you a "weirdo-0.00001%marketshare.xxx format???" file, you need to ask them to please send you a PDF.

Most windows users don't know how to make pdf's. They are pretty uncommon in the buisness world compared to .doc's. Having MS Office compatability is *wayyyyyyyyyyyyyyy* more important for most users of koffice than having good pdf compatability, although it'd be nice to have both :-)!