JUN
2
2005

KOffice 1.4 Release Candidate Announced

The KDE Project today announced the release of the KOffice 1.4 Release Candidate. If nothing disastrous is found in this release, it will be renamed and become KOffice 1.4. A Live-CD has been created so that you can try out KOffice 1.4 RC without having to commit your hard disc to it. There are currently no binaries available for download of the release candidate. Read the full announcement and the changelog for more details. OSDir has screenshots of the release.

KOffice is an integrated office suite with more components than any other suite in existence. This release specifically introduces the database management application Kexi, the image editor Krita and upgrades the major KOffice components to use the OASIS Open Document format, an industry standard allowing better interoperability across applications and platforms.

Comments

First Post ;)

Btw, Kongratulations (as suggested last time I post here :D ) for the release candidate of KOffce 1.4. Thanks to all KOffice developers :)

Cheers

fyanardi


By fyanardi at Thu, 2005/06/02 - 5:00am

nice work !! congrats !!

how many developers are working on Koffice now ? are there more now ?
what sub-projects lack developers ?

curious,ch:,.


By ch at Thu, 2005/06/02 - 5:00am

I'm not sure how many people are hacking on KOffice right now -- there's some fluctuation. Since I became maintainer of Krita about a dozen developers have contributed to Krita -- some with lots of code, some with one essential patch, others with icons. And then there are the translators (who have a perfect right to clamor for my blood seeing the amount of trouble Krita gave them this time).

Kexi gets reasonable amounts of love. KChart has been picked up, too. There are quite a few people interested in KSpread, but that's the type of application you really need to have about half a dozen dedicated people working on. Kivio is already quite good, but I don't doubt that Peter would welcome someone to help him develop the application further.

Two applications that really need a strong and dedicated push are KWord and Karbon.

KWord is quite good, but a word processor is a central application in an office suite and needs constant development.

Karbon once had the chance to be the first and premier vector graphics application. Neglect has let Sodipodi and now Inkscape grab the lead, but if someone with a bit of stamina gets really enthusiastic he could make great strides. There's also an easy task for someone who wants to dive into Karbon: implement rendering vectors and fills with patterns. It's one of the things that still make Karbon crash.

I'd really love to work together with a Karbon maintainer to make sure Krita and Karbon really fit together -- from basic widgets to sharing a rendering model so you can integrate a karbon layer in a Krita image and vice versa.

I'm determined to stick to Krita, to resist getting distracted by other apps, because I believe I would never achieve my vision if I divide my effort. I'm not going to develop another app besides Krita. But cooperating to make sure that KOffice is also the creative suite that rocks is quite another thing. That's high on my list of priorities.


By Boudewijn Rempt at Thu, 2005/06/02 - 5:00am

I just wanted to say how glad I am for your work folks! I installed the beta some time ago, and I was amazed at the quality of krita - it is going to be a great replacement for gimp (at least for certain tasks).

Really really nice work, thank you!


By Csaba Molnar at Fri, 2005/06/03 - 5:00am

> KWord is quite good, but a word processor is a central application in an office suite and needs constant development.

Dont get me wrong - but I consider KWord to be the least important part of KOffice (KSpread is the most important, since in business you more often work with money ehm... numbers than text).
Well, let's see what KWord is used for: People writing important texts (for which they are paid) use Kile. People creating Presentations use KPresenter (contra OOo Writer which is used more often for this task than OOo Impress). And People editing pure Text use Kate. So, what need for KWord is there? None.


By german User at Fri, 2005/06/03 - 5:00am

Er... I think you're wrong here. Kile is a great application, but I don't think it would see a lot of use for writing business letters, proposals, specifications, reports, or memo's. There's a lot more to business than numbers... And you just don't use a latex frontend in business, you use a word processor.


By Boudewijn Rempt at Fri, 2005/06/03 - 5:00am

i disagree. i expect a well-educated to be able to write LaTeX fluently. and so far i have not been disappointed. if not, get a new one.
their job is to care of the context (since that's what gives money) not fiddling around hours on layout, fonts and so on.
of course, you need a pretty large collection of templates and they are mostly spcific to your enterprise so there's no common pool to use, but once you have them using them is pretty fast and easy (and saves you from a lot of faux-pas)
well, theres one disadvantage: when getting letters and offers my eyes sometimes hurt looking at bad fonts and shabby layouts. esp when french accents and japanese hiragana are placed wrongly or even completely missing sometimes. it's a sing of bad management and a clear indication to not make deals with them. may seem a little harsh, but when economy is going down (as in germany) you have to focus on everything, even the tiniest things


By Benni at Fri, 2005/06/03 - 5:00am

No doubt KWord and KSpread (with KChart) are the most important K*Office* applications. They are very central to how an office is run. Almost as important, but much less used, would be Kexi, the database application.

In fact (and sorry, Boudewijn), I would hesitate to say that Krita belongs in a pure office suite at all. It would fit better in a DTP suite together with, maybe, Karbon and Scribus and some other programs of the same type or perhaps an artists suite.

That is not to say that I think that Krita should be thrown out of KOffice, only that such programs don't get much use in an office.

And now to something completely different. As part of the KOffice team, I have some plans for the future. One thing I would like to do is to make a survey of how KOffice is used, and which features are missing. We should also look into previous investigations, e.g. from Microsoft, to find out how people do use office suites. And then we should implement *these* missing features, not other features.

With the risk of making me unpopular here, I am going to pick an example. There has been talk on the KOffice developer list about making KSpread use bignums so that virtually unlimited precision could be had. To me, that sounds like a bad idea. Unlimited precision is nice, but it would also mean a much more complicated code base and probably hamper other developments. What we need first is to actually get people to use KOffice before we go out and implement features that only a infinitesimal part of the users want.

Instead, we should implement list handling functions and fix annoying bugs because this is what keeps people from using the programs. Microsoft found out, much to their surprise, that handling lists was the most common use of a spreadsheet, not making elaborate tables with formulas. And KSpread is still lacking in this area! And that a long buglist is making a program less popular is a given.

We need to establish a significant and growing user base that likes the speed of KOffice and that wants the tight integration between KDE and KOffice. And we need to do this *before* we do fringe features. Otherwise KOffice will drown in the upcoming massive deployments of Open Office.


By Inge Wallin at Fri, 2005/06/03 - 5:00am

I have never said that the definite precision values are to be done *now*.

However KSpread used much memory to define a cell, as it used the values one after another instead using something in the idea of a QVariant. So this has/had to be changed (not sure if it was done or not in KOffice 1.4). So I thought that taking care about possibliy extending KSpread in such a direction should be taken care of.

Also when dealing with currency, as far as I know, you need exatcly 4 digits after the decimal. That too can be done with definite precision (just set it to 4).

As for KOffice "drown" in a OOo wave, that is for me exactly a reason to have functions that normal office suites do not offer.

(As for when and who will actually implement define precision, that is a totally other question.)

Have a nice day!

PS.: for real numbers there is no inifinite precision usable on a computer, see for example pi.


By Nicolas Goutte at Fri, 2005/06/03 - 5:00am

Oh, I quite agree with you about Krita -- it's been discussed on our mailing list, too. It's that the KOffice framework makes a lot of features really easy to handle, like filters and templates and so on. But a tighter integration with digikam and Karbon is high on my list of priorities, and that's harder to do from KOffice. And we'd like to do releases more often than KOffice does.


By Boudewijn Rempt at Fri, 2005/06/03 - 5:00am

I think you seriously misunderstand common office workflow. The wordprocessor is central to almost everything.

Derek


By Derek Kite at Fri, 2005/06/03 - 5:00am

Go away troll, why makes a stupid discussion 'Kile vs KWord'.

The word processor *is* the most important application of an office suite: it is the one that is the most used!


By renox at Sun, 2005/06/05 - 5:00am

> I'd really love to work together with a Karbon maintainer to make sure Krita
> and Karbon really fit together -- from basic widgets to sharing a rendering
> model so you can integrate a karbon layer in a Krita image and vice
> versa.

Wonderful! :)


By Helder Correia at Fri, 2005/06/03 - 5:00am

And now for an energetic Karbon maintainer :-).


By Boudewijn Rempt at Sat, 2005/06/04 - 5:00am

Krita is truly amazing!!!! I can barely hide my excitement ;-)
For years - if not decades - many in the Linux community (especially
those not using Gnome) have wanted a replacement for GIMP with
its annoying multi-windows interface cluttering your taskbar.
Now we're almost there it seems. A fact I needed some to get used too -
so long have we been waiting for a decent graphics editing app.
Furthermore, CMYK support now might really become a reality in the near future. GIMP has promised this for ages for the "next" version but so far I dont know of any steps in terms of program design that might get it there apart from some dubios non-functional auxiliary scripts. So Krita is good for all those who really want to dump Windows+Photoshop. Until now - let's face it -
this is just not possible for everyone who must work with graphics
professionally.
Kudos to everyone involved!!


By Martin at Thu, 2005/06/02 - 5:00am

Well... and all that. But insanely great as Krita undoubtedly is -- there's a way to go before we've got the features and precision to beat Photoshop or Corel Painter. CMYK is pretty close indeed, and I had really some hope it would make it into the final release, but apart from the niggling bugs, there are some issues with making it not only usable, but also useful.

The main problem is that I haven't got access to anyone with the requisite domain knowledge. It's an interesting thing to work on, but it's also something I don't need, personally. I'm really pleased when someone tells me they fired up Krita and managed to paint without getting frustrated. That's where my personal thing is.

I'm a linguist, a theologian, ultimately a Java coder for hire -- not a print professional. I haven't got a clue about the workflow from image to press...
Which means that initially, cmyk will mean nothing more than that -- having four additive channels instead of three subtractive in your image.


By Boudewijn Rempt at Thu, 2005/06/02 - 5:00am

What about contacting the scribus team? They're knowledgeable abot the printing process and since it uses Qt, there may even be some pieces of code to get there?


By Richard Van Den Boom at Fri, 2005/06/03 - 5:00am

I really love to see KOffice becoming better and better..
Thanks to all the KOffice developers :-)


By Dario Massarin at Thu, 2005/06/02 - 5:00am

really thanks for the work. i really depend on Koffice, as its the only office suite i have :D

so i'm very happy to see it get better.

i used ms office today, 2003. well, that's some nice piece of work, i have to admit. not on every front, but it has some nice things, really. but hey, they have many people working on it - and koffice is free!


By superstoned at Thu, 2005/06/02 - 5:00am

Am not an artist, but tried it the other day and drew some silly stuff with it. (looked like a teched out Worms level...)
first advanced paint app I could just pick up and draw with :)

(is there any way to use the alpha channel in gradients, eg, have it grade from 100% transparent at one end to 0% at the other?)


By Gábor Lehel at Thu, 2005/06/02 - 5:00am

Thanks for the compliment!

About the gradients: try the autogradient section in the Tools paintbox. Right-click on the gradient bar to add or remove segments: set the opacity and the color for the endpoints of every segment using the color wells and spinboxes underneath the gradient bar. We don't have a facility for saving custom gradients yet, I'm afraid I have to admit.

The opacity setting in the gradient tool panel is for the gradient as a whole; I guess that's what you tried to use at first.

There are some usability issues with the current division between tool panels and Tools option sheets -- at this very moment I am dithering between reworking the tools/tool options system along a design we completed earlier but didn't have the time to implement, or making the tabs and sheets in the palette windows drag & droppable...


By Boudewijn Rempt at Thu, 2005/06/02 - 5:00am

Ah, thanks, that's what I was looking for :)
(was indeed looking at that opacity option, and the preexisting gradients... didn't notice the autogradient tab for some reason)


By Gábor Lehel at Thu, 2005/06/02 - 5:00am

I share the growing interest in Krita, especially since the desire seems to have something closer to Painter than Photoshop.
My wife and I are using Gimp and the Gimp Gap plugin to make animation movies (you can see some images here, we're working on a real website : http://svdboom.free.fr) and we're rather satisfied by it, but the gimp team doesn't seem eager to go the paint tools way so having Krita doing it would be a wonderful complement for us.
The fact that Krita supports pipe brushes and xcf files is also very interesting, since we use heavily both. This would allow us to work basically the same way on the same files with both tools, using Krita for instance for layouts and Gimp-GAP for animation.
However, I found some issues for this plan right now :

* XCF import is not perfect. There are issues with transparencies, for instance. Do you plan to improve this in the future? Since XCF is an open format, why not using as default format?
* Pipe brushes work but we use pipes defined in random mode : each a pattern is printed, one random layer of the pipe is selected. With Krita, is seems to me that the layers are not selected randomly. This is annoying, as the main use of this great feature is to introduce some level of hazard which makes a drawing look less computer-generated.

Anyway, I'm very looking forward to painting tools like watercolor in Krita. :-)

Best regards,


By Richard Van Den Boom at Fri, 2005/06/03 - 5:00am

Cool work!

We currently use ImageMagick to import xcf files -- improving the imagemagick xcf filter is on the todo list, but hasn't been done yet. I decided to keep Krita's own file format for a couple of reasons, the most important being that we can add any kind of stuff that way. For instance, I'm working on a watercolor simulation. Things like the current state of the cellular automatons for drying the wet paint would have to be saved, too, otherwise images would dry immediately on saving. Basically, we have different needs from the Gimp for our file formats -- but I definitely need to work on the filter.

You're quite right about the pipe brushes. The pipe brushes problem is something I simply forgot to put on the todo list -- it was one of the first things I worked on. The thing is, the Gimp uses a parasite that determines how the brush is used, and I haven't yet implemented a parser for those parasites. And I was wondering whether I hadn't better implement compatibility with Paintshop Pro's pipe brushes. And, of course, you cannot create brushes, let alone pipe brushes with Krita at the moment...

This area needs a little work; I'll put it on the new todo list, and it might also be a good idea if you were to add both items (xcf imp/exp & pipe brushes) as bugs in bugzilla: that way you'll get informed if I get down to doing work on it.


By Boudewijn Rempt at Fri, 2005/06/03 - 5:00am

Thank you for the nice comment. :-)
Now that you said it, I understand why the outlook I get when importing XCF files is indeed very close to the ones I got when I tried to manipulate these images with IM. I should have thought about that.
It's funny how little support there is for the XCF format in open source, while it's one of the older free formats. That's too bad, IMHO.
I don't think not being able to create pipe brush in Krita is that a problem, as long as you can use the ones created with Gimp or PSP, for that matters. I don't know the latter and what they bring to the painter, just remember that Linux users can easily fire Gimp to create new brushes, but are less likely to do that with PSP. :-)

Anyway, I'll open the bugs (more like enhancements to me) right away.
Is there kind of a roadmap of the things you want to implement?

Best regards,


By Richard Van Den Boom at Fri, 2005/06/03 - 5:00am

Well, the Dimp developers explicitly discourage third party apps to implement or use xcf because they want to be free to change the format whenever they need it. It's not meant for an interchange format.

The current roadmap is at http://websvn.kde.org/trunk/koffice/krita/TODO.


By Boudewijn Rempt at Fri, 2005/06/03 - 5:00am

OK, but they could at least provide a library supporting the various versions of XCF, a bit like libpng, libtiff or libjpg.
I understand that it's their decision, but I find it too bad.
Oh, well.....

Thanks for the links.

Best regards,


By Richard Van Den Boom at Fri, 2005/06/03 - 5:00am

How good is KOffice at printing?

With the current KDE, nothing prints as it should.


By KDE User at Thu, 2005/06/02 - 5:00am

Huh? IME kde printing works perfectly, indeed I use kprinter to print from things like mozilla and acroread. What problems are you having? Anyway, koffice uses the kde print system, so koffice will print as well or badly as it does.


By mikeyd at Thu, 2005/06/02 - 5:00am

KDE uses the exact same print system that Mac OSX uses.

I have had no problems whatsoever with printing under KDE. KWord (previous versions) has had problems with overlaid graphics, compositing them correctly on screen but printing them incorrectly, but that was an old bug in KWord, not in the print system.


By Evan "JabberWok... at Thu, 2005/06/02 - 5:00am

If you are referring to the kspread printing issues, I think most of them were fixed.

Derek


By Derek Kite at Fri, 2005/06/03 - 5:00am

Wouldn't the printing quality also depend on the printer driver? For instance, I have an HP Photosmart printer and when I print digital images using the printer's own feature (you can plug the compactflash disk into the printer direct), the quality is fantastic. However, even when using hplip and the latest hp psc driver, I cannot print as good an image using software (KDE or GTk).


By Kanwar at Fri, 2005/06/03 - 5:00am

... and sorry for posting the above twice. I tried to get the grammar with print quality v/s printing quality right, actually :-)


By Kanwar at Fri, 2005/06/03 - 5:00am

by using koffice applications, we the users can improve it by reporting what's not working as expected, and also what's missing which is important to get our work done!

please use and report the problems, instead of just whining that it is just not up to the mark (like ms word or open office).

btw slackware 10.1 package:
http://ktown.kde.org/~binner/klax/10.1/koffice-1.3.98-i486-klax.tgz


By Asif Ali Rizwaan at Fri, 2005/06/03 - 5:00am

AFAIK, MS Office 12 will use the XML file format. So will KOffice (OASIS). Will that make it easier to support MS Office files in KOffice?


By Claus at Fri, 2005/06/03 - 5:00am

yes. the current .doc files are proprietary, and hard to read properly. the xml files should be easy. unless microsoft insists no certain restrictions. like "you can't use this fileformat for free software" or they embed certain binary, hard-to-read-but-essential parts in the fileformat.


By superstoned at Fri, 2005/06/03 - 5:00am

Easier doesn't depend on XML or not.
It depends if the format is documented well or not.

Current MS Office formats would be easy to implement, if only they were documented. So, if the new office xml format isn't documented and available for free, then there's still the same problem.

Well, that's what I think.


By Tim Beaulen at Fri, 2005/06/03 - 5:00am

KOffice has always used XMl for its files. It has just changed the XML file format. Using XML is just a base, it does not mean that a programm can read any XML file because it can read one type (similar with writing).

(In comparison, you could tell that using XML is like telling "this language uses Latin letters". With that assumptution you can do a few more things that if you were not sure which kind of letters you can use. For example one could stupidly copy a written text, as one knows the letters, even if one cannot understand the language itself. But you can also see how many languages are based on Latin characters in the world and that people speaking one of these languages cannot understand the other. Similarly with XML.)

And as written by other posters, the main problem for file formats is and remains the documentation.

Have a nice day!


By Nicolas Goutte at Fri, 2005/06/03 - 5:00am

MS Office 12 will be using a (supposedly) open xml (but not OASIS) format. Time will tell how "open" it really is, or how easy it will to interoperate with it.


By Rex Dieter at Sat, 2005/06/04 - 5:00am