The KOffice team today announced the second maintenance release of the 1.4 series. Among various bugfixes and translation improvements, the KOffice 1.4.2 release further improves support for the OASIS OpenDocument file format and interoperability with OpenOffice.org. Also, Karbon, the vector drawing application has been much improved. More changes are listed in the changelog. Binary packages for Kubuntu and SUSE have been contributed and a Klik package is being prepared right now for those who want to test this release without installing it first (testers are welcome).

Just as native as the old native format, that's to say, it's implemented in the applications themselves, not as a filter from and to a native representation. But it's not yet the default format: that will happen with the 1.5 release, which is scheduled for the end of January.

In the klik bundle, I'm including a few documents, describing some things you can do with it (like start up in different languages, and start up the different applications individually, instead of just via koshell (the Everything-Integrating Office Suite Environment).

All these documents I've written with alpha versions of the bundle itself.

After I had readied different 1-page documents, I decided to put it all in 1 multi page document. I did so by copying and pasting the formatted content from the first into the second, onto empty pages. It worked flawlessly.

I've tested between OOo en KOffice, and there it doesn't work. I'm not sure why not, actually, but there's probably something complicated with clipboard standards and so on involved; it's something that should definitely be looked into.

Please! Could the klik package be made "self contained" so that it doesnt depend on debian libs ? Something like a self-contained directory ? (with very basic external dependencies). I have been having fun kliking around in Mandriva, but only some self contained packages (are they called bundles? ), like Firefox, etc. really work fine (which is expected anyways)

### 'Could the klik package be made "self contained"'
----
Yes. Of course. The "self-contained" is exactly the base idea of klik.

### 'so that it doesnt depend on debian libs'
----
Why?

Debian libs work great. ;-P

Even on other distros...

The most important thing for getting the klik package work on as many platforms as possible, is to avoid "bleeding edge" compilers and library dependencies, and avoid dependency to libstdc++6. Debian Sarge is just about perfect for that. You better make sure that your distro (Mandriva) ships with Kernels that support loopmounting cramfs images (this has been the major hurdle for Mandriva users utilizing klik).

We can't include *everything* without making the self-contained AppDir bundle reproduce and mirror a complete Knoppix system.

We do include a few "known" things, and tweaks that take care of various naming conventions in between distros for the same library.

Having said that thing about Debian -- in this case I used SUSE-compiled binaries (because I couldnt find any Debian packages of KOffice yet).

I'm currently working on a fix for a problem with the included docs and translations (they are not used or shown). Unfortunately, I didnt find many alpha testers for it (but thanks to you two, CyrilleB and Dennis_p!). Looks like everyone enjoys the finished free cake, but no-one is prepared to help the baker do some work....

Once it is ready, I'll announce a download URL, and a bit later a klik://koffice link will also work.

Thanks for all the info and clarifications. I'll give the klik a shot when it is done. Unfortunately, these days I have very little time to contribute to free software. I'll contribute again when I get a break ... from life!

As per cramfs. I am running Mandriva 2006.0 and it seems to be working.
Right now I am runnning the klik for kmplot, and here is my mtab:

Now that KOffice is using the OASIS format natively, would it be possible to reuse the OpenOffice excellent import/export filters from the MonopoliSt office ? Last time I asked, it was impossible, because the OO code was very convoluted and monolitic. Have they refactored stuff for OO 2.0 ? It would be beneficial for everyone, including them. If their filters could run as stand-alone processes, people could write scripts to transform all the documents in a large installation of MS office to OASIS, etc.

And for KOffice, many people who are not using it now could start using it immediately if this functionality (better interoperability with MS office documents) was available.

I'm sorry to have to say that the OOo filter code is still the same convoluted unintelligible mess that appears to directly poke stuff into the internal OOo datastructures that is has always been -- so, no, unless you want the type of solution where KOffice uses OOo automation to first convert an MS document to an OpenDocument document and then load that. But that would, of course, be horribly slow and hackish.

We need better filters, but that's one thing that's nearly impossible to achieve in ones copious spare time; you really have a couple of full-time people for that.

That's sad to hear. Hopefully they will consider cleaning up and refactoring for 3.0. There is a general consensus that both their code and their build system needs a major rewrite if they are to succeed in the long term. Just building OO is , by itself, a challenge. Not to mention porting, or trying to hack code into it.

The alternative would be to try to coordinate in FreeDesktop.org , or maybe within oasis, to write (maybe roll up sleeves and try to extract it from the OO mess) stand-alone filters (from/to different formats to/from oasis). Oh well, wishfull thinking. If people from KDE, Gnome, freedesktop.org, etc. pull together maybe this is attainable. I wish I had some time to help coding ...

It could allow non-ms office utilities to directly convert a .doc to .odt or (od?) so that other applications could use it.

I wish oo developers should consider a "Document viewer" and/or "Document Converter" commandline, so that other applications like abiword, kword, etc., could use ms filters to get a readable .odt or .odp or .ods file.

Kind of makes you wonder.. is it World Domination (TM) they are after? If people have to load up the entire OO to convert documents, then why would they need "crummy little koffice"? ;-)

But speaking of this.. the a2ps (anything-to-postscript) is a killer app! If we eventually got a "a2od" product, this would make life a whole heck of a lot better for everyone (except M$ ;-). Being able to convert even dvi, pdf, wpd and the more exotic formats to OpenDocument too with a right-click maneuver on both GNU/Linux and win32 could speed up the transition quite a bit... or do you all think I'm barking up the wrong tree? :P