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.
Still, it's clear that we're all working towards ODF support, haven't reached it fully yet. Not OpenOffice, not KOffice, nor anybody else. That said, it's encouraging to read things like:http://www.openmalaysiablog.com/2007/01/bidirectional_m.html.
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...
ODF standard - that sometimes sounds more like wishful thinking.
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!
Even better; there is a testsuite.
http://testsuite.opendocumentfellowship.org
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.
i can agree 100% to the persons complaint, i use koffice on my freebsd machines and openoffice in my girlfriends laptop and interoperability is hell.
i even get better results exchanging files in .doc
a plain text with two pictures created in openoffice and opened in koffice is a mess! the pictures are in wrong places, the fonts are bigger in kofffice, certain pngs dont load at all...
i am not saying its koffice's fault, but you really need to work with ooo on interoperability!!!
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
I'm a KDE user all-around, but still I need to use OpenOffice if I need
some compatibility with the MS Office, which, sadly, is the ACTUAL standard.
Sorry but this isn't the way to go, peek into OpenOffice, do what you want
but at least .doc (word) and .xls (excel) document compatibility should
be granted (and actually isn't ).....
Feel free to be the umpteenth person who tries to mooch the MS file format code from OpenOffice... Unless you've tried you don't realize just how impossible a task it is.
As for us, we're going for OpenDocument. Even Microsoft will soon be forced to support it.
http://ariya.blogspot.com/2006/04/why-koffice-not-using-openofficeorgs.html
You misspelled 'definitely' as 'definately'. :-)
Now send me my cookie!
Okay, I'll send it via an HTTP Header :P I hope you find it tasty.
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. :)
Hmm, but they didn't catch the extra 'to' in 'comes to time to print'? :)
Maybe the grammar checker will!
What's wrong with 'when it comes to time to print'? It's a bit clumsy but not grammatically incorrect as far as I can see.
Devious!
Very nice article; many thanks :)
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.
AFAIK you can define a color scheme per application
So you could define another color scheme for koffice
You're kidding, right? Are you seriously claiming that you don't use an office application because you don't like the background colour behind the documents? I find that really hard to believe.
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.
Both these issues are already done in svn. You'll be able to switch when 2.0 comes out :)
see this old image that shows page-spreads and the page spacing;
http://members.home.nl/zander/images/200606-KWord-PageSpread.png
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.
Currently that feature you don't like is not implemented; the background is always the paper color :)
This is a controversial feature indeed; I'm sure that if we re-add it we will do so with a config setting.
I believe KWord and co. could become killer applications for people moving to KDE.
I really hope KOffice 2.0 is a big success, and I would like to say a big thankyou to all the KOffice devs!
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.
Yeah, I'm concerned as well. Text appearance has always been my major problem with KDE apps, and everything I've read about Scribe indicates that this will fix all of those problems.
...so screenshots that still have these problems make me nervous. This'll be fixed in the final version, right guys? Anyone?
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 ;-)
Hi,
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.
This is a coordinated effort between the KWord + Qt + Pango guys.
See http://www.freedesktop.org/wiki/Software/HarfBuzz
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.
Agreed!
My first reaction on all these screenshot is 'ugly', and I have real difficulties to 'forget' the poor font kerning.
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.
This is a pre-pre-pre alpha release, guys.
Please take it like that and don't burn something that actually is quite is step up from the previous release because its not perfect yet.
Celebrate progress, be patient for perfection.
Well, unless you want to submit patches ;)
Oh I wasn't burning, I was trying to understand your comment. I am excited about the upcoming 2.0 version of KOffice.
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..
> then you'd better use fonts which render correctly to really
> show-off your work
You are right. I'll correct that right here and now.
I've been working with type years ago. Must have gotten rusty.
The one attached to this post better?
Not really, this font is really weird: the 'u' is bigger than the 'm'..
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!
This font doesn't look *that* good. 'b' and 's' seem to have more space around them than some other letters.
Thanks a lot for these articles!
They provide exactly the information, I long to get.
And someone beat me on definately ;)
Best wishes, and keep it up!
Arne
Hi,
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.
Thanks!
a few kde libraries wont really do much damage, a full loaded kde desktop isnt required.
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?
it's not dcop, it's loading all the libs and starting necessary support daemons such as kded and what not.
you're probably not saving as much with xfce as you think if you're running kde apps in it.
Yes, I agree. I guess that's sort of my point, is there any way to make Koffice compile as Qt-only or something?
No, but you could try AbiWord perhaps?
The simple answer is no.
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.