Moving towards the 2.0 release with almost monthly beta releases, the KOffice team has once more honoured its promise to bring out beta releases of KOffice until the time is right for a release candidate. So today we bring you this beta with many, many improvements across the board. Incremental as it is, this beta is an important step towards a final release. So here it is: full
announcement and changelog.

Highlights of the 2.0 beta 5 Release

The developers have been working very hard fixing bugs and removing incompatibilities and other misfeatures. This can be seen in the rather large list of changes. Here are some of the highlights of this release:

Significant Progress with OpenDocument Saving and Loading

Much of the work on this beta has been concentrated in making loading and saving OpenDocument files more complete. A lot of effort has been put into making KOffice interoperable with OpenOffice.org, since that is the most important OpenDocument editor today.

KOffice loading a document from OpenOffice.

All Reported Crash Bugs in KWord Fixed

KWord has received extra attention that removed all known crash bugs. We want to emphasize that at this point it is extremely important for users to test all components of KOffice and report all bugs, especially crash bugs.

Together with the Bugsquad team, a Krush day is going to be organised on Sunday 25th
January 2009, to help find new bugs before the final release.

Comments

hi there everybody!
a loong time ago, i read in the "road to kde 4"-articles (nice name btw) about a odf-library. is this peace of software already existing? so that it could be shared between open source-projects/kde-components?
thanks!

i hope it does. I just tried Kspread2 on a ODS file that had been converted from XPS and it got most of it correct, a few cells lost its "number" format and became "generic" in Kspread2 and got weird values displayed. Once i reformatted the cells to "number" it was fine.
I, as a normal user, tried to open an XLS file (owner root:root - i forgot to chown it first) by mistake in Kspread2 and it just sat there and didn't warn me that either it was the wrong format or had the wrong permissions. I had to terminate Kpread2 to get out of that one.

I've submitted a bug report (#18098), with sample attachments, for the formatting issue.
The opening of the XLS issue seems to have gone away, i think i was just impatient as i'm using KDE4 with a nvidia board and its still slooooow.

Actually it's Impress and not Draw, and the other application in the screenshots is KPresenter. The point is to show interoperability between KOffice (Kpresenter in this case) and OpenOffice.org through the OpenDocument file format.

but it would be nice to have in the future a good support also for the office formats.... some people still send files in .doc or stuff like that (and obviously i reply with an .odt)... but if koffice want to be quite popular it should consider this thing (ovbiously after the other more important stuff like a good/perfect support of the open document format)

The excel filters have just gotten a big boost yesterday. The .doc filter is quite good already, it's kword that cannot yet display everything kword can. Using koconverter to convert .doc to .odt gives quite nice results, as can be verified with OOWriter.

The excel filters have just gotten a big boost yesterday. The .doc filter is quite good already, it's kword that cannot yet display everything kword can. Using koconverter to convert .doc to .odt gives quite nice results, as can be verified with OOWriter.

At the moment I only have a Ubuntu 8.10 and Windows Vista dual boot. Because I don't want to 'pollute' (don't get me wrong, I will certainly switch from GNOME to KDE 4 once it's a bit more mature) my Ubuntu installation with KOffice and all it's dependencies on Qt and KDE, I'd like to test on Windows.

However, last time I checked with the Windows installer, KOffice beta 4 wasn't available, merely an older beta AFAIK. When will beta 5 be packaged for Windows, or is it already available?

I don't know about the windows release -- that's for someone else to answer. But yes, if we are not satisfied that we've reached a release candidate stage, we will release more beta releases than are planned right now.

Ok, the lowdown on the windows builds is that Patrick Spendrin no longer has a windows build machine. That's why we haven't got packages right now -- which is a pity, but it also offers an admirable point for someone else to step in and start helping out!

I hope KOffice 2.0 will be really stable as KDE 4.2 is now. I think KOffice 2.0 final can be released also next year if this can produce something very stable and usable. I'm a great fan of KWord and KPresenter and I'd like to see a good release also if this means other 12 months :) .
I will try to use this version to report bugs to fix in time for the 2.0 final stable release.

I *suspect* that 2.0 will be very similar to KDE 4.0 and Amarok 2.0 - i.e. not very full-featured or stable releases pushed out to get more testing and also to afford some psychological relief by ending the feature-freeze so that the devs don't feel stifled. As with KDE 4.0 and Amarok 2.0, I then would expect rapid progress in fixing bugs and restoring features.

2.0 won't be the end of the road for KOffice, that's for sure. And there will be regressions from 1.6 -- sometimes really important regressions, like a complete lack of table support. But we are committed to making 2.0 as stable a release as we can within its set of features. And yes, it'll be relief to finally have it released and be able to start working on 2.1 again :-)

But we do need the help of all you guys in the quest for stability. No matter how stupid and obvious you might think a crash or a bug is: the fact that it's in there means we didn't know about it, so please report it! We need people to test KOffice before we release the final, otherwise we _will_ release a KOffice with lots of bugs.

Yes the dot article saying that kword got all its crash fixed, is for all *reported* crash, it's as much a display of progress than an encouragement to test things, and report new issues, so that the devs can make 2.0 rock :)

Yep, I have the same issue. Anytime I attempt to save a KWord document, it crashes. However, since I am running Mandriva cooker I hesitated to say anything until I ruled out a packaging problem. Since you have the issue as well, it seems to be a KWord issue. Of course my main issue that I always bring up is not being able to save flake shapes within a KWord document. That very well could be resolved, but since I can't save a document at all now there is no way of knowing.

The incredible bug fixing rate within the KDE4 project(s) IMHO shows what a powerful new framework KDE4 is.
Soon stability and feature equivalence to KDE3 will be reached, and then KDE4 will just beat the s..t out of other DEs (including M$ & MA¢. ;-)

i think that the total lack of table support is a bad thing which will cause some/a lot of people don't use koffice util that is fixed :(
btw, will koffice adopt the same release cicle of 6 months as kde has ? (for the releases after the 2.0)

OpenOffice is my only office suite, and I use it for both general and academic work, always saving in the ODF format. I too would like not to depend on OpenOffice, and have a "native" Linux suite. But if you want to work with ODF, OpenOffice (and derivatives) is the only choice. I will only consider KOffice when its ODF implementation is 100% compatible with that of OpenOffice.

But the good news is that KOffice and OpenOffice are getting more and more compatible, as both teams are solving odf problems in their implementations. You will see significant improvements with the 3.x releases of OOo and the 2.x releases of KOffice.

Just a query as why kspread2 uses an extension of FODF instead of ODF if using ODF format when saving a spreadsheet. I was assuming that ODF format would ave defaulted to the same extension to show that it can be opened by any ODF compliant program - will this not be confusing to the ordinarty user?

That sounds vaguely familiar... I had the same problem this summer: .fodt is one of the valid extensions for odt documents and added by OpenOffice. I discussed this with David Faure at the time on #koffice:

1.07.2008-15:33 < dfaure> it's just an _extra_ pattern for this mimetype. odt files are still associated with the mimetype too.
01.07.2008-15:34 < dfaure> it's just that the file dialog has to pick _one_ extension as the default one, and there's no real support for that anymore with shared-mime-info;
01.07.2008-15:34 < dfaure> no replacement for the old X-KDE-NativeMimeType property.
01.07.2008-15:34 < dfaure> so it takes the first extension from the list, so the bug is that fodt is first. I'll have a look at that.
...
01.07.2008-15:41 < dfaure> (hmm I see, update-mime-database uses a hash internally so the order isn't kept)
...
01.07.2008-15:47 < dfaure> ok, no fix possible with current shared-mime-info; I emailed the xdg list. I knew this problem would arise, just didn't have a use case for it up to now
01.07.2008-15:48 < boud> cool :-)

It is an option actually saying "Automatically select filename extension (.fods)" at the bottom of the "Save As" dialog, so it seems correct. and it say similar on the kword2 "Save As" i.e. "Automatically select filename extension (.fodt)"
Seems like a strange choice of extension guaranteed to add confusion.

As these messages are hard-coded on the dialogs (i think) it doesn;t appear to match David's thoughts.

Well, no, the messages really aren't hard-coded, but constructed out of the available patterns. If you, for example, grep through the KOffice source code, you won't find a single instance of .fodt in source or ui files.

Karbon has an excelent curve editing tool in 2.0, which is on par feature wise with inkscape. Of course, Karbon misses a lot of the other feature of inkscape, the biggest thing it currently miss are filters (especially the blur one ;) ).