In this week's edition of the Road to KDE 4, we'll take a look at
the up and coming KWord 2.0 as part of the KOffice project. KWord 1.6.1 is
already a powerful KDE-integrated word processor, but with KDE 4
technologies, KWord 2.0 promises to be among the most powerful free word
processors available. Read on for more details.

KWord is part of the KOffice suite of applications which, with a few exceptions such as Kexi, has been visible thus far as a KDE-only application living under the shadow of the much larger OpenOffice.org suite. But this won't always be so, as the new KDE 4 technologies allow KOffice to exist as a native application on other platforms such as Windows and Mac OSX. Look out for more details on KDE support for these platforms in a future article.

One of the biggest assets of KOffice and KWord is its native support for the OASIS OpenDocument standard, which is shared by many office applications these days (including OpenOffice.org, Google Docs and others). Expect improved ODF document compatibility for KWord in the future as the developers strive for complete specification support.

Lets take a look at some screenshots from the development version of KWord. Notice the nice anti-aliasing of every element of the UI. On my system, it doesn't appear noticeably slower than KOffice 1.6.1. One of the most improved areas in KWord 2 is the text formatting and layouting, which definitely deserves some more exposure. It's not yet complete, but as you can see below, it's definitely much improved from previous versions. You really have to experience it yourself to appreciate how smooth moving, resizing and rotating Flake shapes is in this new version.

All manner of objects are being converted to the new Flake library, for instance KFormula elements, so you can insert nicely rendered math into your documents without any trouble. This support could make KWord as exciting to use for page layouts as KPresenter, as you are no longer restricted to dull, square document shapes. These changes should enable KWord 2 to behave as a respectable basic desktop publishing application.

Also noticeable in this early preview version is the lack of spell checking support, as this is being reworked for the upcoming Sonnet architecture for spelling and grammar corrections. (Which word did I misspell in my screenshot?)

But this is not the only improvement new to KOffice 2. Also in the works is scripting support for applications through the new and extensible scripting framework dubbed Kross. It has received a lot of work and looks to be one of the killer features of KOffice 2.

The following screenshot shows the new scripts menus in KWord:

Also notice how I moved the tear-off toolbars from the previous screenshot. I placed them by drag-and-drop, and they automatically tabbed up. This is all done very smoothly by Qt with no noticeable interface flickering.

Of course, the same scripting and rendering features have made their way into other KOffice apps as well. KSpread and scripting are a perfect fit, and there is a lot of power exposed to the advanced user.

For people interested in more details about Kross, check out this article on the development and usage of Kross in KSpread.

These are just some of the many improvements in the works for KWord and KOffice when the KDE 4 platform rolls out. Of course, these screenshots are of the development versions, which are quite unstable at the moment, but jugding by the level of activity today in the developer channels (like #koffice on irc.freenode.org) there is a large amount of momentum behind this release.

KOffice has a separate release schedule from KDE 4, so they may or may not release concurrently.

Comments

I'm really looking forward to the next KDE and associated programs. And I'm really glad to see these articles about the progress.

With KOffice my biggest concern is ODF compatiblility not so much the UI, just read an articlen in Linux Magazine about it and the compliance in the different tested office suites were somewhat depressing (they did the test on an older version 1.5, so most have improved since).
Compatiblility between OOo and MS Words .doc, seemed better then between OOo and other ODF-enabled software, which is sad since ODF is an actual standard and .doc isn't.

Linux Magazine was, well, less than thorough and the author didn't quite understand the issues involved. I was a bit unimpressed with the articles. Thomas has got my copy now, so I cannot look back and give definite criticisms.

KOffice allready is looking very nice, but I have to agree with ODF compatibility problems. I recently switched to Koffice from OO.org, but switched back, after exchanging documents turned out to be a nightmare. This is not necessarily have to be a Koffice-problem, could also be a problem of OO.org. But how can the user figure out where the problem lies and has to be reported to? Since OO.org is more used, I now use OO.org again.

The user could check the same document in different viewers, but in the end he can't be sure which one is right. The devs have to look into the ODF spec. In some cases the incompatibility might also be caused through inaccuracy of the spec.

I tried to reproduce our masthead, which we have in openoffice and M$Word, in KWord and in Abiword recently. It was a nightmare. The OpenOffice version is attached to this posting.

In Kword, I was able to create something which at least looked similar. In Abiword I wasn't even able to create something similar. Once I got close, but then closing and reopening the file (native Abiword format) messed everything up again.

Opening the odt file in another ODF compliant application is a different matter though. Try to open the attached masthead with KWord, and it will be all messed up. In Abiword it's the same.

My recreation of the masthead in KWord will also not open correctly in OpenOffice, not to mention Abiword...

Your masthead doesn't look very complex, but you did choose to use some items that are not well supported in OOo (frames).
The alternative is to use an anchered image, which may take some tweaking, but will give you better results. The KWord support is not 100%, but it should be enough

Anchored content in 2.0 are in design right now, but they really look like they will be awesome!

The tests are written based on the spec, not on the implementation of one application. There you can see how well or bad each app behaves in each section. (people willing to make screenshots of the tests in different versions of the applications, please report to; http://www.opendocumentfellowship.org/~testsuite/ )

Do note that ODF is pretty new; its expected to see compatibility grow over time as applications find bugs and fix them.

There's still work to be done, but already there are benefits from a common format - as KOffice has improved greatly in the recent releases I've been using it more and more on documents I created in OOo without having to think about doing a conversion first

But yeah, the KOffice people caught that mistake during proof reading, but since I didn't want to bother creating a new screenshot (being lazy as I am), I managed to turn it into a positive mention for the upcoming Sonnet spelling and grammar engine. :)

I'm really liking this series, Troy - it's providing a great deal of interesting tidbits, and providing some nice visibility into the KDE4 development process. Thanks for putting it together! (And thanks for all the KOffice guys, too, for their excellent work in providing some a comprehensive, lightweight and well-integrated suite!)

...will it support changing the background colour away from the KDE UI settings? That's the reason I don't use KOffice, because I like my dark grey colour scheme, but I don't like document backgrounds being dark grey.

I dont use Koffice by two reason, sheet color what changes as neutral-gray what i need to use because editing pictures, and i would like to have sheet paper as white so i can see what it would look like on paper with pictures and other objects.

second reason is that sheet papers dont have any space between them. It's more like toilet paper what you are writing and it just dont look good. I made few wishes for middle sheet and those were taked to use so paper is on middle but there is no space still between sheets... when it comes, koffice will go over OOo.

In case you wonder; the page fully in view is a 'pagespread' which means its one page that will be printed to be 2 pages. Some people need that. The direct effect is that you don't see a split in that page. But the other pages lower will have the spacing.

With Scribe, the new text layouting engine, these issues should be fixed with KOffice 2, and most text in the first screenshot looks good so far with regard to this.
Still, i found some issues which still show some spacing issues:
- second paragraph: the first "text" looks like " t ext"; in the second "text" the "xt" looks quite condensed; "technical looks like "t echnical".
- the paragraph below the red arrow: the dot after "dynamically" is moved into the word. Looks like wanted kerning (compare with the other dots and the comma after "library", second paragraph)
- Most obvious: both of the rotated paragraphs look quite much much like the old dancing characters: almost all characters are somehow tilted and are a tad off of the ground line, moved a bit up and down. Didn't pick any words, should be visible with all of them. Looks more abvious on the two-line, stronger rotated one.

What's the reason for this? Is this what you mean by "not complete", so does this get addressed with time, so it's not like this can't be fixed like in KOffice 1.x?
I know it's a work in progress and it's only stacking up right now and still rough around the edges; still I wanted to point it out, as I thought this was already gone with the new layout engine and to make sure these issues don't get overlooked.

let's hope so. at least it got better already, and this is so much a work in progress i find it hard to believe they won't spend time on it. even if you do daily SVN updates, the progress on Koffice is amazing - they easily change over 60 files each day, frequently adding more than 10 or 20 files... it's a very active KDE module.

Ops... it really looks bad, just the same type of problems that were plaguing 1.x. Hmmmm, I really, really hope that this is due to not using more advanced text rendering features that *will* be turned on later during development (anybody can confirm / decline ?). BTW - it seems to me that with such text rendering KOffice can be only treated as a toy, not a real tool ;-)

I'm personally already quite impressed with the way that things look a magnitude better than KOffice1.x
I do grant you that there are several slight problems. (see http://bugs.kde.org/show_bug.cgi?id=139130 for instance)

Not all issues have been solved even in the bugreport issue, but they are solvable. And we aim to solve all of them in time for the release.

I followed your link, and it seems to be saying that the remaining rendering problems aren't due to issues with KOffice 2.0 code but rather issuess with the fonts that were used. I'm I correct in this understanding? If so, does this mean that only fonts that have been optimised for KDE/KOffice use will display correctly? That could be an issue.

Correct it's issues with the font used. But it's not about beeing optimized for KDE/KOffice, it's about fonts having good/correct hinting. The bad font's will render just as crappy all places that use FreeType.

Anyway I think KOffice should default to a better font than the one used in these screenshots. Using that particular(crappy) font gives a bad impression of KOffice. It's about first impressions and using a better font will help a lot.

I just wonder, instead of what happened with the kerning: where did the hinting of the fonts go?

The UI has nicely hinted letters (Vera Sans most likely, and using the hinting instructions in the font), but for some reason it produces awful fuzzy blobs in the document itself, even though it seems that the same font is used there. If this is really Vera Sans there, then either the font rendering in the document is broken or the person who made the screenshots has some weird settings.

I should install kde4 and koffice2 myself once to see how it looks like, the screenshots posted here don't really tell enough to see what's going wrong.

It isn't burning either, but if the issue is just with some fonts as said above, then you'd better use fonts which render correctly to really show-off your work: even when trying, it's hard to overcome the 'ugly font rendering' first impression to appreciate your work..

I wouldn't say "not really" I'd say "yes!" Because it *is* better. It's not perfect, as you noted the 'u' is taller. Assuming that's not intended by the font, then it's less than perfect, but without the kerning issues.

Thanks Thomas and all the other KOffice devs, we really do appreciate your hard work!

Glad to see that OOo might be getting some tougher competition! Does anyone know if it is possible or if it will be possible to create a Qt-only version of Koffice, which does not require all the KDE deps? I ask this because a low-resource office suite is desperately needed in the Linux world, and I imagine that most users who are using an old computer aren't going to be running KDE.

So, on Debian, it would require kdelibs or something like that? It's just I remember when I used to use XFCE on an old computer, if I opened even something little like Kcalc, it took ages to load. But I suppose with DCOP being gone, that will help the initial overhead quite a bit?

The long answer is due to all the functionality that KOffice pulls in from kdelibs so it doesn't have to do all that work itself. Like the file dialogs, config dialogs, toolbars, printing, auto-saving, config backend, kparts, and so forth... removing the kdelibs dependency would cause KOffice to re-implement this all in-house, so you really wouldn't be saving anything.