The November issue of Linux Magazine presents a thorough review of KOffice 1.4 written by Marcel Hilzinger. While based on an older version of KOffice, KOffice 1.4.2 has just been released with many fixes, the review is fair, thorough and balanced. It was useful too, within two hours of having read the review Thomas Zander committed the first fix for a problem mentioned by Marcel. It is well worth a read, and not only because of the praise heaped upon Krita.

On another note... is Karbon being properly maintained again now? It's completely useless on my PowerPC box, since it renders colours incorrectly (the white when you start it up is cyan, for instance). The bug report has basically been ignored, and when I last contacted the maintainer, he advised me to use another program. If it's going to stay at that level of functionality, I'd rather see it removed from KOffice, so that others realise an alternative is needed.

Yes, Karbon is maintained again. If you look at the release announcement (http://koffice.org/announcements/changelog-1.4.2.php) you see that there are a host of improvements to Karbon. However, the endianness issue is probably not easy to solve with the current Karbon rendering backend, especially when it is very likely that none of the Karbon developers has access to a ppc machine.

When my powerbook was still working well enough I gave fixing the endianness issues a shot, and failed. Nowadays I'm not even sure that Krita is okay on ppc...

For KOffice 2.0, Karbon will likely use a completely different rendering engine -- KCanvas or Arthur or maybe even Xara's engine that's going to be opensourced really soon. That should solve all endianness issues in one fell swoop.

That's odd indeed, anyway I use kpdf 0.5 from the 3.5 branch so perhaps that's why it works for me. I did not think the render part of kpdf had changed much since 3.4, but they may have slipped in some bug fixes:-)

Anyway I did a md5sum of the pdf, does your match: 8f9e57be0809dbbc49a378a5ee3744e1. If it does, well then you have to wait for 3.5:-) (or Use KGhostwiev).

Conversely, proprietary doesn't mean closed, locked and undocumented; it just means that one entity "owns" -- is the proprietor of that file format. Which is true for the KOffice file formats. And documented... If you count a dtd as documentation, then, yes, it's documented, but I know for a fact that I've procrastinated on updated the dtd for the Krita file format for about a year now.

I recently installed Suse 10.0 and tryied to live a bit without gtk apps.
As I upgrated to KDE 3.2 beta1, everthing was fine, konqueror in this version is almost catching firefox, kopete is great, konqueror instead of gftp...

But then I got to krita instead of gimp. Krita is nice, I really liked it's interface and tools, but I missed one feature, the one I most use in gimp: Paste as New Image. Without this I can't be produtive in krita, so I installed gimp, too bad. But I hope this will be implemented soon.

Why do you want to include it only in KWord? Why not make an implementation like with kspell, making it accessible from all over KDE. Then you would not only have spell, but grammar checker too in web forms when you use Konqueror. Cold be usefull for some, don't you think?

Implementing grammar checking as a KDE-wide service like KSpell should be a nice self-contained project for someone who wants to dive into KDE hacking -- maybe something for you? Could be a lot of fun and very educational.

Actually I do want to learn KDE hacking. I'm learning Qt4 right now and once I have sufficient knowledge I'll learn KDE which will probably KDE4 by the time.
Here is my first Qt4 project http://p80.free.fr/katiuskapagina/ (a reworked of a previous Kommander project of mine), it's very poorly written I guess but it's my first Qt/C++ app :). And yes that would be a great start for hacking in KDE but it seems a little too difficult for now :(