Submitted by The KOffice team is proud to announce the 1.6.0 release of its office suite. This release is mostly a feature release of Krita and Kexi, but also contains major enhancements to the OpenDocument and MathML support of KFormula and new scripting functionality. This version also contains a vastly improved version of KPlato, our project planning application.
KOffice 1.6 Released
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
looking forward to seeing it in SUSE 10.2
I wonder if they’ve sorted out the font spacing issues that made KWord 1.5x nearly unusable for me?
No mention of the font issues in the press release.
On Ubuntu 5.10 + KDE, KWord had font spacing issues, OO crashed all the time (seemed to work under plain Gnome though) and Abiword had buggy support for styles. Before I switched over to Lyx, I began to wonder if I was even going to be able get a word processor up and running under 5.10.
No, the font problem is basically a Qt problem. Thomas is working really hard to make that particular problem go away in 2.0.
Actually, my comment sounded a bit harsh and ungrateful.
However, on that occasion I really didn’t seem to be able to get a word processor working at all!
I wonder if they’ve sorted out the font spacing issues that made KWord 1.5x nearly unusable for me?
All OS that don’t use the “new” rendering introduced in Mac OS X have this problem : which means everyone of them.
These problems are in MS Word too for example. They hardly make word processors unusable.
This is plain stirring the matter very very far, and so plain FUD. There is nothing unsuable in this problem.
It’s just annoying if you’re very picky.
On Ubuntu 5.10 + KDE, KWord had font spacing issues, OO crashed all the time (seemed to work under plain Gnome though) and Abiword had buggy support for styles. Before I switched over to Lyx, I began to wonder if I was even going to be able get a word processor up and running under 5.10
You have a very big problem with your system, which is probably your own doing that you are aware of but won’t admit.
And Lyx is not a word processor in the same way as KWord or oowriter. It’s based on LaTeX, which is another kind of itself.
Ookaze: All OS that don’t use the “new” rendering introduced in Mac OS X have this problem : which means everyone of them.
I’m not quite sure to what you are referring here, so if you are referring to kerning by default, that’s hardly new. TeX does it from day one and OOo2 is quite capabable of doing it with a suitable font such as DejaVu. This is no attempt to be inflammatory, i might have got you wrong, but kerning isn’t new.
I’ve been installing koffice since 1.5 and although it is on the right track, it is still miles behind being remotely usable. For example, kword isn’t even capable of presenting tables correctly, kspread crashes when editing text in cells, karbon12 isn’t even capable of correctly loading the files saved by it, etc.. And I’m talking about koffice 1.6 beta1.
KOffice sure has potential but right now it is nothing more than that. Maybe in the future it becomes usable for basic features but right now it is even far from that.
I have been using koffice 1.5.2 and have not encountered some of the problems you identify. Tables work perfectly in kword for me (even complicated tables), and kspread has never crashed for me when editing text in cells. However, I think it is certinaly usable for basic features and more, but it is not without its problems. I had so many problems with OpenOffice that I decided to try out koffice, and have to say I’ve never looked back.
You load betas on your PC and then you want to tell us what is right or not ?
This is stupid.
My wife use Koffice since a long time and has yet to have these kind of problems. But then again, I don’t load betas on her desktop.
Yes, KOffice has some problems, but basic features are there and never caused problems here.
Well said!
The problem is that some people try an early version of a product, have a bad experience, and then forever slate it without realising that that product has since moved on and improved. It reminds me of when people slate KDE for being bloated, slow and always crashing – well this might have been the case many years ago, but things have moved on. I suspect this is what is happening with Koffice, people judge it purely on their experience of the beta version or when they tried it many years ago.
I tried KOffice many years ago. I used to use KDE (probably RedHat 6.0) on 486 DX2+24MB RAM+Hercules monochrome graphics card
It was hardly ever crashing.
Back to the KOffice: too bad it’s not preinstalled by default in many distros along with OpenOffice.org. KOffice have never crashed for me.
I see you failed to understand what I said.
The bugs I mentioned are present in koffice since 1.5 and they still persist in koffice even in the fresh versions like 1.6 beta1 and 1.6. The problems I mentioned aren’t specific to beta releases. They are specific to KOffice and they exist for at least 3 final releases.
I try to use koffice (specially kword and kspread) everytime a new version is released but it still can’t shake off their bug problems. Maybe in 2.0 it can but right now it is unusable. Anyone who really tried to make anything with koffice knows about that, even the developers mention it in their blogs.
Although KOffice in general has a long way to go, I must say I’m impressed by the fast development pace of Krita. Now it has CMYK support, and it becomes more and more a GIMP alternative…
Keep up the good work guys!
I agree with you. Krita is shaping up to be a very good graphics app and I now use it a lot more than I use GIMP because I like the interface and I can do most of what I need with Krita.
Personally I wish Krita would be seperate from Koffice and be a standalone app.
Personally I wish Krita would be separate from Koffice and be a standalone app.
Except for the shared code in the KOfficelibs, Krita does not depend on anything else in KOffice. Like the other applications in KOffice you can use it standalone, without all the others if you wish. So removing the benefit from sharing development resources and code by separating it from KOffice makes very little sense. And even less since it can be done when compiling from source, or by any decent distribution making their packages.
People regularly ask about that issue (I should add it to the faq, maybe) — but the thing is, being part of KOffice frees me, as a Krita hacker, of a lot of work. I don’t have to do window handling, file loading & saving, import/export filter architecture and so on. And with 2.0, our text tool will be provided by KWord, we’ll have nearly automatic integration with Karbon.
The thing is this: KOffice is a suite for both sides of your brain. Analytic and creative. Content and presentation. Words, numbers and images.
That’s how I want it to be — and that’s how we’re going to make it.
Although KOffice in general has a long way to go, I must say I’m impressed by the fast development pace of Krita. Now it has CMYK support, and it becomes more and more a GIMP alternative…
A “GIMP alternative”? This is pathetic… GIMP is a piece of crap compared to Photoshop. Every major GIMP release, I try it, and basically GIMP hasn’t improved over the years. Basic features and missing in GIMP.
Personally I wish Krita would be seperate from Koffice and be a standalone app.
Yes, me too.
Personally I wish Krita would be seperate from Koffice and be a standalone app.
Yes, me too.
Tough luck then because it seems to be going the other way (ie: integrating further with the rest of KOffice).
The integration is a good thing. It can be installed separately anyway (ubuntu does that), why then not sharing code with other projects, especially if it helps krita and kexi to move faster, and if it helps the rest of koffice to move as well, both benefit from it. Every piece of Koffice can be installed separately from the rest anyway, unlike openoffice.org, so it beats me that people think it’s better off separate. :s???
I really really really want to like KOffice. It’s small and fast, nicely integrated with KDE, and has some fairly innovative features. They have some great things on tap for KOffice 2.0.
But let’s get the basics down. The limited MS office compatibility does lead to crashes. Opendoc? I just tried to open an .ods file created in OOo2; KCalc locked up for nearly 4 minutes before finally showing a 50% accurate representation. So much for that.
Having said that, as standalone applications for people looking for a light office suite that don’t really need to share documents with non-KOffice users, it’s pretty good. Plus Kexi appears to be developing much better than Base in OOo2. And Krita is becoming a hands-down killer app for KDE.
I just kind of wish the fundamentals were a little more solid. The seem to be targeting features other packages don’t have while ignoring core functionality. Unfortuantely I’ll have to stick with OOo2 for heavy lifting with spreadsheets and documents, but I’ll keep watching to see how KOffice progresses.
I have the feeling 2.0 is going to be more like KDE itself: good and decent core library’s that only have to be created ones, for one functionality. This will make development easier (with flakes), and will need less resources (development wise). So I’m hoping for 2.0 to lead the way to a great office suite.
I think that you’ve hit the nail on the head: It’s always disappointing when a app seems feature filled but doesn’t have core reliability. For example, I’ve never run a version of Abiword (Win or Linux) that didn’t seem distinctly buggy.
KOffice is small and fast but for me, it still has some show stopping bugs. In general, I prefer to use a KDE app, if I can.
It’s a great project and I am looking to what 2.0 has to offer.
It’s always disappointing when a app seems feature filled but doesn’t have core reliability. For example, I’ve never run a version of Abiword (Win or Linux) that didn’t seem distinctly buggy.
KOffice is small and fast but for me, it still has some show stopping bugs. In general, I prefer to use a KDE app, if I can.
…can only support your comment – had the same experiences …
//Opendoc? I just tried to open an .ods file created in OOo2; KCalc locked up for nearly 4 minutes before finally showing a 50% accurate representation. So much for that.//
You seem to be assuming here that OOo2 is the one that got the .ods format right, and KOffice has it wrong.
This is not necessarily the case at all.
There is still work being done on spreadsheet formula standardisation in OpenDocument format. AFAIK, KSpread actually has the most correct implementation, not oocalc.
Had that problem too. Using Type 1 fonts (i.e., postscript) instead of truetype ones is the only way I’ve found to get around it (until the Qt4 based release comes along).
NOTE: Postscript fonts won’t look so great on screen unless you zoom way in due to the low dpi, but they sure print great.
I always use the “standard” linux fonts with no problem, Docs print fine. I would agree that Windows fonts will appear with spacing problems. I don’t have stability issues with kde “light” themes.
As others said I think it’s either a XOrg, xtt (truetype font renderer) or QT problem not the KOffice itself.
As a tip, for spread sheets I use Gnumeric. It very good in 90% (if not 100%) of the needs I have.
I’m not using OO.org much. Just a personal un-preference.
I havent tried KOffice or GnomeOffice before. It sounds interesting but have a few questions:
Is it any better than OpenOffice? How compatable is it with Microsoft Office? Does is support the Open Document format?
It’s almost totally non-compatible with MS Office – no export filters, and not-so-good import. Well, good enough to READ what someone wrote, but don’t expect to have a good looking MS Word document in Kword…
It’s behind on OO.o in some areas, and imho a few of the basics aren’t that good yet, mostly due to limitations in the underlying tech (Qt 3.x) but these most likely will be fixed in 2.0 (approx 6 to 8 months away).
On the other hand, it’s much faster than OO.o, has more components (so more functionality, including some very nifty things) with better integration (with each other and KDE) and is easier to use.
Krita and Kexi deserve some extra points, as those two (painting and database) are much better than other available apps on linux (Gimp and OO.o Base).
Best point for Koffice: it’s developing at a much faster pace than OO.o, so in a few years, you’ll run it anyway. Better start right now 😉
Does is support the Open Document form?
Yes, it does. In fact one if the KOffice developers, David Faure, is part of the OASIS workgroup that create the OpenDocument specification
//How compatable is it with Microsoft Office?//
Barely. That of course makes it a lot more compatible than Microsoft Office is with it.
//Does is support the Open Document format?//
Yes. Hence it is very compatible with OpenOffice. In fact, both OpenOffice and KOffice are compatible with each other, and both are a lot more compatible with Microsoft office than Microsoft Office is compatible with them.
Yes. Hence it is very compatible with OpenOffice. In fact, both OpenOffice and KOffice are compatible with each other, and both are a lot more compatible with Microsoft office than Microsoft Office is compatible with them.
Unfortunately that’s not the case. KWord and OOo2 layout pages differently, so it’s very easy to wind up with documents displaying differently or with slightly wonky formatting in both. I’ve also run into cases with KCalc and Calc not being compatible with functions or cell formatting. On top of which neither has actually implemented the full Opendoc spec, and in a few cases are interpreting it differently. So while you can share files between the two, you can’t necessarily count on them being compatible. Yet.
At one point I was using OOo2 to open MS files, save them in .odx and then trying to use them in KOffice. It failed more often than it worked, almost always with Excel files. Which makes me wonder, though, if the KOffice team can’t try and extract the MS-code handling from OOo2? It would certainly help.
But your point is taken. At least there’s far greater compatibility, in intent and implementation, than Redmond is willing to offer anyone.
Have they fixed the “Sun has patents on OpenDoc” problem yet?
It’s unbelievable that people are judging Kword for on-screen font kerning (annoying but not an actual problem per se) and Microsoft Office compatibility.
In case you haven’t heard, MS Office doesn’t share its formats with *any* third party. Not one office suite in the world can load all MS Office files perfectly except MS Office – and it has compatibility problems galore between older and new versions itself. This argument, for me, is the bottom level of cognitive sloth.
Re: OOo documents in KOffice – here’s the problem… KOffice is ahead of OOo in terms of OpenDoc support and OOo spreadsheet doesn’t save in fully compliant format. KOffice is not 100% compliant yet either. Over the next year, expect data from them both to be fully interchangable.
Since QT is available for OSX why isnt there a Mac Version?
Because it is tied in with KDE – that is why it is called KOffice. I think 2.0 should run on Windows and OSX.
Because it is tied in with KDE – that is why it is called KOffice. I think 2.0 should run on Windows and OSX.
The real problem is that Qt wasn’t GPL’d on Windows and OSX prior to v4.x.
KOffice 2.0 will still be tied to the KDE libs, but my understanding is that the work done on some of the interface layers like Solid should alleviate many of the actual system dependencies for KDE to *nix.
I *believe* you’ll be able to package KDE/Qt libraries for non *nix platforms, I won’t go as far as to say that KDE apps will run natively in other environments and they’ll still have to be ported, but they’ll certainly run more smoothly without requiring X, or cygwin, etc. etc.
Expect to see KOffice, Konqeror and Amarok, among others, running on multiple platforms.
I’m not a dev though so take this with a grain of salt, this is purely pieced together from what I’ve been reading in the dev blogs subject to my own artistic interpretation. And maybe some hopeless optimism as well.
The real problem is that Qt wasn’t GPL’d on Windows and OSX prior to v4.x
Almost correct. Qt3 has been available under GPL on OS X, but Qt/Win32 only since Qt4
The Kexi maintainer also maintains a Win32 port of the basic KDE+KOffice libs and Kexi and is being paid for that by his employer, some company in Poland IIRC
… But not the way you think.
Indeed, I have never been really a Qt fan. But the developers behind KDE are writting very good applications. They put as much as they can in it in terms of usability and program features. And I like that.
For the past 6 month, one of my friend at work was so engulfed by Qt potential, that when we had to write a simulator for our application, he choosed Qt whereas I wanted Gtk. I let him do, and it became like a challenge.
So we started developping with Qt3.3, and went on for 6 month. I know it’s not the last version, but it’s still widely used. Seriously, we run into problems after problems with Qt, with the library itself I mean. The way things are done. May be we were asking too much, having too high expectations. At one point of time, even my friend felt disappointed. So I was telling myself that we missed something, that it must be better than what we thought. Especially browsing on Internet, you find rants like the eternal Qt/gtk war, but real comments on Qt alone, not so much.
Well to begin with, Qt has a poor threading capability in Qt3.3, and really it’s a shame. You are obliged to deal with a lot “magic” just to get multi-threading works, because it only deals with signal and slots (events) as long as they are managed… by the main thread! Second, text modification in a large QListView sometimes crashes the application, it just can’t handle it. Third, Qt tries so much to replace everything, I know it was created when STL did not exist yet, but it’s time to drop their containers in favor to those of the STL (I haven’t tried Qt4 yet for that, so I hope they just wrotte wrapper around the STL). Finally their socket high level classes are not good enough when it comes to open many different sockets on different port at the same time. Multiplexing functionality is inexistant. Since you have to write it yourself, you end up using system calls, that you have to mix with Qt library, and it gives headhacke sometimes.
So when I see what the KDE developpers are able to achieve with Qt as a base, I am truly amazed. I wanted to have a look in the code of one of these app one day to see how much of Qt code they use (only the rendering part, a la Gtk, or really every single class they can).
We gonna port our app to Qt4, I am in charge of it, so I really hope to see a lot of improvement. I wanna try going on with Qt even if it’s not my primary choice, but just because I want to know how KDE developers make it so great with it!
Anyone has a experience with Qt please feel free to share…
because it only deals with signal and slots (events) as long as they are managed… by the main thread!
No, Signals&Slots also work in other threads. Just like with any other method call you have to be careful when crossing thread contexts, but since a slot invocation is a method call that is to be expected.
Finally their socket high level classes are not good enough when it comes to open many different sockets on different port at the same time
Hmm, maybe you are using the event loop driven QSocket instead of QSocketDevice and threads.
It works with QSocket, but has better performance with QSocketDevice+threads when the data processing after receiving or before sending takes some time.
We are doing quite complex applications here at work, including standard GUI, specialized visualizations and non-GUI/server processes.
As far as I remember we had only one threading problem in over four years, and that was actually a bug in libpthread on certain SMP kernels.