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. Download packages for Kubuntu, SuSE or you can try before you install with the KOffice 1.6 live CD.
The 1.6 release is intended mainly as a feature release for the two fastest developed components: Krita and Kexi. However, other components are being actively developed too, with astonishing results. The highlights of this release are:
- Krita Becomes Usable for Professional Image Work
Krita and its maintainer Boudewijn Rempt won the aKademy Award for "Best Application" at this year's KDE conference in Dublin. With features such as magnetic selection, effect layers, colour model independence and full scriptability, it has risen to become what is probably the best free image editing program today.
- Lots of New Features in Kexi
Kexi, the desktop database application competing with MS Access, is the other application in KOffice that is already the best of its kind. Kexi has received over 270 improvements since KOffice 1.5. With this release, Kexi gains such features as the ability to handle images, compact the database, automatic datatype recognition and Kross scripting tools.
- KFormula Implements OpenDocument and MathML
The formula editor of KOffice now supports OpenDocument and MathML and uses it as its default file format. It also surpasses the equivalent component in OpenOffice.org, scoring 70% on the W3C MathML test suite compared to 22% for OpenOffice.org Formula. We see this as one example where the work to provide a very well-structured codebase of KOffice pays off to create a superior support for the existing standard.
- Scripting Support in KSpread, Krita and Kexi
This will be the last non-bugfix release until version 2.0, which will build on Qt 4 and KDE 4 technology. For more information, see the full announcement, the detailed release notes page, and the complete list
"Since inks and papers differ (and with them the color gamut) [...]"
James Richard, I see you have some idea about color gamut already. That's an excellent level educate yourself a bit more beyond these basics. I suggest you start up Konqueror and type "wp:gamut", "wp:RGB", "wp:CMYK" and "wp:color management" into the address field and do a bit of read up.
It will teach you that even one RGB monitor differs to the next one. And one CMYK printer model to its neighbour. And a Scanner to the next.
All of these need to be adjusted with a color management software to match each other as closely as possible, if you do some sort of professional printing. (Most home PC users may not need it -- serious amateur photographers however do long for it!)
That's why CMYK support in Krita is absolutely essential. And I tell you one more thing: CMYK support in Krita would be absolutely useless if it wasn't accompanied with color management support (which is, I believe, in this case supplied by the LCMS library).
Please stop bemoaning CMYK support in Krita just because you own an RGB printer (or a CMYK printer, whose crappy driver uses RGB as input.)
The color gamut of a printed page is determined by the ink and the paper.
What this means is that the range of colors that can be produced is determined by the ink an paper.
The color gamut of you monitor can be interpreted in two ways:
1. The actual colors which are being displayed.
2. The range of off monitor colors which FF0000, 00FF00, 0000FF represents.
IIUC, it is #2 that color management software addresses. This works just the same with RGB since the color gamut is always an RGB function -- in the ideal case it is a triangle between a Red, a Green, and a Blue point.
> Please stop bemoaning CMYK support in Krita just because you own an RGB
> printer (or a CMYK printer, whose crappy driver uses RGB as input.)
I am not bemoaning anything. I did seek to point out that you don't need CMYK to print on the printer attached to your PC. If the driver accepting RGB input is "crappy" then all of our Linux drivers based on GhostScript are "crappy".
I am amazed at this superstition about CMYK. "The truth is out there." You use the "crappy" driver to convert a linear RGB image to a (printer specific) non-linear CMYK image which I hope is compensated for the color failure of the inks. The reason that you use the "crappy" driver to do this is that it has the needed information specific to the printer which is needed to do this. If you made your own CMYK separations in Krita and were able to directly print them on your printer, you would NOT be happy with the results -- the "crappy" driver (usually GutenPrint) does much better.
"The objective of printing is to produce an RGB image."
No, it's not.
The objective of (quality) printing is to produce an image on paper that matches as closely as possible the intentions of the artist, the photographer, the document writer or the user. (And this intention may well be "the printout and all its color shades must exactly match the picture I can see and adjust on screen".)
The colors used could be based RGB, sRGB, CMYK, CcMmYyK and many more spaces...
James Richard, the world does not evolve around your RGB fixpoint only. Like it or not.
Well, my eyes see RGB. Therefore, ... .
"Well, my eyes see RGB."
True. Mine as well.
But the "world" of digital imaging and printing does not only consist of our eyes, but also of paper, inks, toners, monitors, rays + tubes and more, which all influence the outcome.
In the end, there is again light reflected from a printed image which enters our eyes and is detected by our RGB-only light detectors.... OK, in this sense, the world *does* indeed orbit around RGB, and I must retract -- no, rather modify -- my above statement:
# The world orbits around RGB, but there are other
# components to this world but just that RGB axle.
Not really. Your eyes see RGB+gray scale. Cones and Rods and all that. I'm color blind, so I don't really see RGB, more like R1R2B, where R2 is somewhere between red and green - a very different color from red. There are many different types of color blindness (hundreds at least), but only 10% of the population have enough to matter. Even those who are not color blind have some shifting from "normal". So you think you see RGB because you are not color blind, but the colors are see are unlikely to be "a scientific standard" (AFAIK no such thing exists) RGB.
Your perifferial vision is mostly black and white, your vision in front of you is color. And there is also that blind spot. Depending on how you look at an image you get different combinations. Your brain is smart enough to fill things in so that you don't realize this is happening, but it does.
Odds are you knew the above already, but never considered it. You should.
CMYK is the best chance we have to cover all that complexity, which is why professionals use it. It still doesn't cover people like me very well, but it is pretty close for 90% of the people. When colors are really important professionals will buy an ink in that color, but each ink requires a separate pass through the press (some presses can do more than one color in a pass), and each pass will be a little misalligned from the previous, so this is rarely done anymore as CMYK is almost always close enough and there is no missalignment problem.
A few years back my brother was assigned to calibrate a $60,000 CMYK printer. To some Pantone (tm) color - the closest that printer could do was visually different from the standard. A $100 inkjet was able to get it perfect (at least as far as anyone could visually see, color blind or not). So lets not pretend that CMYK is perfect, but it is what professionals use.
(P.S. Anyone know when Microsoft is going to update their stupid browser to get spell check - something Konqueor has had for year? I wish I was allowed to use something better here)
> ... the closest that printer could do was visually different from the
> standard. A $100 inkjet was able to get it perfect ...
This is an inherent problem with CMY or CMYK printing. In CMY photo printing it is called color failure. I presume that with ink that this varies from ink set to ink set. The problem is that the secondary color dyes aren't perfect. The Magenta ink absorbs some Green and the Cyan ink absorbs some Yellow. The Yellow ink is usually not a problem. So, what happens is that when you combine two of the CMY inks, you get a little Black. With photo printing you have to make masks to compensate for this. With CMYK it is simpler. A printer driver that compensates for color failure subtracts this extra Black from the K channel. However, this still means that there is a maximum for saturation and brightness for the primary colors -- the reduced gamut. With ink printing using more colors helps eliminate this problem.
Most printers (even cheap inkjets) have their inks and toners in CMYK.
Yes, your screen is RGB.
And yes, *some* printer drivers use (and require) RGB input.
But *no* -- don't think that means "there is RGB in my computer all over the place".
What format your computer uses internally is something else ("CoreGraphics Engine" [CGE] for Mac OS X, "Graphic Device Input" [GDI] for Windows, and PostScript for Unix/Linux) as originating format that goes to the printer driver...
I concur on the great progress on krita. Last time I tried it (I believe it was 1.5), it was pretty frustating (and I made a negative comment here), but it has obviously made *a lot* of progress. Congratulations and thanks, here's to hoping I can forget about Gimp soon.
Please use http://bugs.kde.org rather than commenting here, so your report will be noticed. Thanks.
I want to encourage everyone to vote for features KOffice lacks of. If the missing feature is not yet filed in bugs.kde.org, don't hesitate to do this yourself. Developers are busy with coding, you know. ;-)
Most developers have a look at these wishes and the number of votes to see where KOffice or any other KDE app needs improvement. Using bugs.kde.org ensures, that your wishes don't get lost due to the fading memories of the species called software developer.
The same applies for bugs.
Some notes about the voting system: You can assign up to 20 voting points to a wish and up to 100 points per product, e.g. KSpread. So you can give 20 points to each of the five most important missing features of KSpread, for example. If you consider more features as important, distribute the voting points among them.
I would rather they work on fixing all the bugs that make KWord, KSpread, and KPresenter unusable. Sadly, if you want to do some actual work rather than just play around with a cool app, OOO is still the only choice on Linux. We honestly tried to stick with KWord at least, but in the end it is just plain not feasible. Import/export from/to MS or at least OOO formats is one showstopper for example. I will try out Krita next time I need to edit an image though.
Bugs are fixed by developers, but KOffice lacks of enough manpower. Hence, we need to prioritize and that are votes for (even though developers are aware of the main issues).
many of the bugs you experience are due to limitations in Qt 3.x, and will be fixed in the 2.0 release. And don't count on better MS Whatever importfilters, they don't want to waste time on that. OO.o support isn't even needed, as OO.o and Kword use the same fileformat. both do still have some bugs in there, but i guess that's something which will be fixed as time passes.
Yayy!! The picture on KOffice website and Cyrille's blog is really nice, looks clean and professional :)
First of all, thanks a lot for your work on KOffice.
I download each release and try to use KOffice for daily use at work.
The suite improves with every release and this is really impressive!
But, at end, I still go sadly back to OO.o with all its defects...
What I lack more are good doc and xls export filters.
It's really sad, but I often need them.
It would be a dream if we could split OO.o import/export filters in a library and include them in KOffice.
As I am not a developer, I don't know if it would be theoretically feasible.
I can ...pray and propose a bounty if someone is interested...
Thanks once more. Emanuele.
For Word you have the RTF filter.
Nothing special with it, just try to save in Word 2003 in 2000 format and you also only get RTF. If you prefer another ending, than do like Word and change .RTF to .DOC.
For Excel it's missing, known issue.
The files you want to import are usually from *other* people. And to tell a customer to send you a standardized format (doc/xls/ppt is a standard for him and he knows no other formats anyway) or how he could transform it into something you can import appears to be... not really the best way.
You should anyway. If enoguh customers scream at Microsoft that their partners are having trouble opening documents, maybe Microsoft will change to a good format (opendoc...) that everyone can open.
There are enough non-Microsoft office products in use that if every user of them made sure to point out the problems they have opening Microsoft documents to partners, the partners would also scream. Loud enough to get Microsoft's attention.
Yes I know not everyone can do this. I specified partners for a reason. You can't inconvience custmers. You can inconvience partners a little, and suppliers had better fit to your needs or you will find a new supplier. (You can even write this into contracts and bid requirements in some cases)
Micorsoft's .doc format is a mess. There is good reason that they use .rtf to save to formats for older versions of word - they cannot understand the format themselves.
I clicked on the "announce" link, then went to the French translation... it is full of mistakes (one per line, and I am not talking about typos here). I think it is far better not to put online any translation than to put a very bad one. I guess it was done by some automatic translation program (google trans, babelfish, etc.).
I'm the coordinator of annoucement translations and I'm sorry the translation is low quality. I sent the annoucement to be translated to a person, if that person used an automatic translator, that is bad. I will check with him.
I don't know if the page has been updated but now the translation is very good for me.
> With this release, KOffice also introduces command-line scripting where, for
> example, spreadsheet documents can be automatically manipulated with scripts
I tried to find some documentation on this feature and how to use it but didn't find anything on the koffice website.
Does anyone know where I could find some documentation on how to use this feature ?
For Krita, see the manual: http://docs.kde.org/development/en/koffice/krita/scripting.html.
A small example for KSpread is up at http://kross.dipe.org/KSpreadInvoiceExample.tar.gz
Do we have doxygen API references for 1.6 up somewhere? They are nice to look at the functions + examples for scripting too.
and some more examples;
and for Kexi, you may also like to look at;
It's good to see KOffice being upgraded from time to time, but I get the impression that the 1.x branch is officially dead in the water. There are issues that won't get fixed until the 2.x branch, such as support for OpenDoc/Word etc... Without them KOffice is unusable by anyone that needs to inter-operate with people who use MSOffice or OpenOffice. This is the reason I gave up on KOffice recently and moved to OpenOffice.
Sorry, but what are you talking about? MS Word support won't ever get better, they don't want to waste time on proprietary sh*t. And they shouldn't.
OpenDocument has been supported since quite some time, it's the default fileformat, so that's not a 2.0 thing as well. It's true 2.0 will fix some longstanding issues, but those are mostly layout issues in Kword, and have nothing to do with fileformat support.
KOffice was one of the first office suites to have native support for OpenDocument, also in a lot of areas KOffice is closer to the ODF standard than OOo, though both suites are still working on it.
And 1.6 release and 2.0 release were being developed at the same time, now that 1.6 is out the door, unless theres plans for a 1.6.1 release, all the effort is going to go to 2.0.
There will be a 1.6.1 release and possibly also a 1.6.2. Those releases will only have bugfixes and no new features. However, errors in OpenDocument handling (a.k.a the OOo) are considered bugs so incompatibilities with OOo should be reported. It's very likely they will be fixed in the 1.6 series.
Regarding XLS and DOC support, it's not exactly that we "don't want to waste time with that shit", it's more like "we have nobody who has prioritized it high enough". We would love better XLS and DOC filters, but at this time we have nobody who works on them.
So when is KOffice for Windows coming out?
With version 2.0, probably at the same time as the Linux and OS X versions. Although that will, as always, depend on people using those operating systems helping out.
The most recent Windows I own is 3.11, and the most reason Windows I have access to through my workplace is Windows 2000...
If you want to have a look for yourself without a newer Windows, you could still test with ReactOS (www.reactos.org), it should probably be far enough to run the KOffice2 suite, as it already handles OpenOffice for example.
I guess what Boudewijn was trying to say is that none of us developers really care enough for windows to go the extra mile to install another OS. Choosing between spending our time on improving KOffice prober or doing auxillary testing we choose KOffice any time.
But given a concrete bug report on how to make it work on windows (patch even more appreciated) I suspect we would spend some time on it. And as Boudewijn said: With 2.0/QT4/KDE4 we will work on windows almost out of the box, so chances are great that it will happen then.
Now, Casper, that's a very callous attitude. I know some developers care very much that KOffice will work on Windows. I am fairly sure that Jaroslaw Staniek, for instance will make sure that it works well when the time comes.
I myself care also, but unfortunately I have never developed on Windows so I wouldn't have any clue about how to do it.
In fact it works already since some time on MacOS and there are already some older packages around. See
that ship has sailed
windows ports will happen sooner or later
the trick will be to balance the risks and rewards
promoting standards will be one of the biggest rewards
porting KOffice and getting more people using OpenDocument will be good for everyone. wouldn't you love it if you didn't have to tell people not to send Microsoft word documents?
i look forward to a khtml/webkit browser on windows so that web developers will have one less excuse for not testing their web pages and following standards. I would strongly favour not porting Konqueror to windows because of the risks of it not being as good as on KDE and giving people the wrong idea. having a standalone khtml/webkit browser instead would help promote standards without risking any of KDEs reputation. unfortunately the swift web browser project seems to have stalled due to financial difficulties.
applications which help promote standards should definately be at the front of the queue when it comes to windows ports
Some people care, some do not.
Like Boudewijn Rempt, the only version of Microsoft Windows I have legal access to is 3.1 (if the disks are still good and I can find a working floppy drive...) I am forced to use Windows XP at work, and I hate it. I personally am not going to put any effort into getting Koffice working on Microsoft Windows - in the end I would have something I have no use for.
I will allow others to do that work if they want. I even wish them luck. But I'm not interested in helping. Many other Koffice developers are the same. (note, though it appears I'm lumping myself in with Koffice developers, I have not actually submitted a patch, only played with the source a little) The question is will those who do care about Microsoft Windows care enough to put the work in to make everything work? It appears there won't be much work, and in that case they will do it. However if it turns out there are major work involved those are care may not care enough to do the work.
I personally don't care to spend any time developing Quanta for Windows. In the past it would have meant thousands in software licenses including a copy of the MS compiler and months of dedicated developer effort in porting. None of our team likes Windows and everyone especially dislikes developing on it.
Having said that it doesn't matter. It's like OS X or BSD... Once somebody is building on it they let us know where our code doesn't build and specific guidelines to make sure the code is cross platform. This usually amounts to very little effort on our part. So we focus on what we wanted to do in the first place, making our application as good as we can, and others make sure we are building on other platforms. In KDE 4 Windows is just another platform.
In my opinion having our applications on Windows is a good start for migrating people to free software... The Qt4/KDE4 scenario is the all the difference in our support for Windows.
"Krita Becomes Usable for Professional Image Work
[...]With features such as magnetic selection, effect layers, colour model independence and full scriptability, it has risen to become what is probably the best free image editing program today."
Krita looks nice on paper (nice architecture, nice concepts,...) but let's have a closer look:
Best free image editing program?
Does it have 16bit? - Yes
Does at least the most basic filters (like unsharp mask, Gaussian blur,..) work with 16 bit? - No
That's a joke, isn't it? I just tested the raw-import feature (it works basically) but then it's impossible to sharpen the image because "unsharp mask" (the only adjustable sharpen filter in Krita) only supports 8 bit/color.
Why is Gimp still extremely popular despite the lack of >8bit/color, color management, CMY,...? It's *not* because of the cool features of Qt4 (gimp uses older versions of gtk), it's also *not* because of it's intuitive ;-) GUI but it's *because* _the_basics_just_work_ and it has very *many* filters and scripts.
Krita lacks filters, plugins, intuitive color adjustment tools,...
That's the main disadvantage of Krita at least from a point of view of an end user. All those rewrites and new Qt4 and KDE4 features _won't__make__Krita__any__better if color adjustments, performance and all the other filter plugins are worse than the corresponding plugins from Gimp or Digikam.
Always saying "wait for the next version" does not work. Who will start writing plugins and scripts for Krita if Krita 1.6 will be a short living bugfix only branch (as krita 1.5 was) and Krita 2.0 will probably be incompatible again with existing Krita 1.6 plugins?
After Krita 1.5 was released (professional photo manipulation software, now with scripting support...) I tried to write a script to do "unsharp mask" sharpening. But argh - Krita had no funktion to do gaussian blur (that's a basic and needed for nearly everything...) - so no script.
Should I write a vignetting and distortion correction plugin for Krita 1.6? I don't think that's a good idea because Krita 1.6 won't see any significant updates anymore (only some bugfixes, if I remember correctly) and Krita 2.0 is too far away (I won't install KDE 4 before KDE 4.0.2 or so).
Gimp does not have those strong dependencies to special KDE or Gnome versions....
Why not remove the feature freeze from Krita 1.6 and have a nice and long living Krita 1.6, 1.7 branch?
> and it has very *many* filters and scripts.
Krita is much newer than GIMP. Give it some time.
> Gimp does not have those strong dependencies to special KDE
> or Gnome versions....
That's because GIMP is already fairly well established and its development (as far as I know) is not moving at a particularly fast pace anymore. When they move to the GEGL core however you can bet that GIMP will depend on much newer libraries in order to increase functionality.
> Why not remove the feature freeze from Krita 1.6 and have
> a nice and long living Krita 1.6, 1.7 branch?
Because there aren't enough developers to work on significant features in Krita 1.x *and* Krita 2.0 at the same time. Qt 4 offers a much more powerful toolset for developers to work with, and to make Krita the best painting tool it has to be developed to take advantage of Qt 4's new structures and features. I think a lot of people don't fully appreciate this yet, and I guess it won't be obvious to many until KDE 4 is released with lots of cool new stuff that Qt 4 has made possible.
> Should I write a vignetting and distortion correction plugin
> for Krita 1.6? I don't think that's a good idea because Krita 1.6
> won't see any significant updates anymore (only some bugfixes, if
> I remember correctly) and Krita 2.0 is too far away
Krita 1.6 will be around for a while in terms of usage, and if you have any intention of using it at all, surely putting work into a plugin now won't be completely wasted if there are still users around to make use of it. Chances are porting a plugin to 2.0 won't be all that hard when it does finally get released either.
> Krita is much newer than GIMP. Give it some time.
Of course. But then they should not call Krita the "best free image editing program".
>Because there aren't enough developers to work on significant features in
> Krita 1.x *and* Krita 2.0 at the same time.
Then I would concentrate on the Krita 1.5 code base. But I'm not a developer.
> Qt 4 offers a much more powerful toolset for developers to work with, and to
> make Krita the best painting tool it has to be developed to take advantage
> of Qt 4's new structures and features.
Wrong, you do not need Qt4 to make a good painting tool. Painter, Photoshop 6, Picasa, Bibble,... all use older and simple toolkits. A image editor does not become magically better only because of Qt4's new painting engine or file dialog. It's all about Workflow, Usability, image editing capabilities and Plugins.
> I think a lot of people don't fully appreciate this yet, and I guess it
> won't be obvious to many until KDE 4 is released with lots of cool new stuff
> that Qt 4 has made possible.
Forget this cool new stuff until the basics work. If Workflow, Usability, image editing capabilities and Plugins are top notch then it's time to think about requiring a new Qt or KDElibs version.
> But I'm not a developer.
Which is why I think you may not appreciate that sometimes in software development, you have to stop working on the currently released version of a piece of software in order to pave the way for future development. Staying working on old versions does have its benefits, but you may spend a lot of time implementing features that would be much quicker to implement once you have been able to rework the underlying structures, which you can't do without risking the stability of the application. In a development version (Krita 2.0 / KDE 4 in this case) you are allowed to change a lot of stuff under the hood that might break things initially but will eventually result in a stronger base for future work. At some point you just have to make that leap.
> Wrong, you do not need Qt4 to make a good painting tool.
> Painter, Photoshop 6, Picasa, Bibble,...
That's a somewhat specious argument - they just wrote their own code rather than relying on a toolkit that is already built. Let's not forget either that all of those products (I assume, since I know of all of them except Painter) were developed by commercial entities with significant amounts of money to spend on development resources, unlike Krita. Some of them, such as Photoshop, have been around for many years and thus are much further along than Krita. It's not a particularly fair comparison.
I wasn't suggesting that Qt 4 is a magic bullet, either - it just provides a much more capable foundation than Qt 3.
> Forget this cool new stuff until the basics work.
People have different ideas about what the "basics" are. Some of the things you consider "basics" might not necessarily be trivial to implement.
Yes, you should write plugins for 1.6. There is a plugin writing manual, there's nothing to stop you :-). You can release it separately and then, when 2.0 stabilizes contact us about it. We can then port it and put it in the main tree for 2.0. I think that Krita 1.6 will live for at least a year from now, and there will be one or two bug fix releases.
By the way: the downgrade message for unsharp mask with 16/bit channel images is a bug: in fact, all convolution filters work just fine with 16 bits/channel images and don't downgrade. (Except for lab, apparently -- but that already works in trunk, too.)
> when 2.0 stabilizes contact us about it. We can then port it and put it
> in the main tree for 2.0.
One of our developers ported his plugins to the trunk codebase in no time. I estimate he spent 1 or 2 hours per plugin of quite reasonable size.
I think its good that you (Max) care and focus on the things that are needed. I'd love to see you put your foot down and convert your activism to productive output.
Oh, and really: here's a hard offer. I will do the porting work for everyone who builds a fun and useful filter for Krita 1.6 and wants his filter in Krita's main distribution.