DEC
18
2003

KOffice 1.3 Christmas Preview

The official release of KOffice 1.3 was originally planned for this week
but since many people are already preparing themselves for the upcoming
end-of-year festivities we are afraid that binary packages may not become
available for all platforms in time. For that reason we have decided to
release a special KOffice 1.3 Christmas Preview for all of you who can't wait
to give this new KOffice a try over the upcoming holidays. In the middle of January, the official version of KOffice 1.3 will be released together
with the usual variety of binary packages.

The KOffice 1.3 Christmas Preview is available for download from:
http://download.kde.org/unstable/koffice-1.2.95

A changelog listing the differences to the previous release candidate is also available.

Comments

Changelog made no statement about krita?

Is it still part of KOffice?

I know there are some activities on the mailing list now...


By Mathieu Ducharme at Fri, 2003/12/19 - 6:00am

Yes, krita is part of koffice. But not in version 1.3 :-(
Let's hope for koffice 1.4/2.0


By birdy at Fri, 2003/12/19 - 6:00am

But it will be released as a first stadnalone version?

Btw. i don't understand why Koffice applications are not released more often.


By Gerd at Fri, 2003/12/19 - 6:00am

Krita propably not. (Kexi might be have a preview.)

As for why not more often: well, find more developers, then may be.

Have a nice day!


By Nicolas Goutte at Sat, 2003/12/20 - 6:00am

It's really and truly and definitely not ripe for inclusion now. I wish it were different, especially since I expect Krita to attract more support and attention when it gets a wider distribution, but at the moment all it has is a strong architecture, a rather unpolished interface and one buggy, completely unfinished paint tool.

However, the Christmas holidays are coming up, and I have taken three days off, so I should be able to spend at least some time on that paint tool, making it fit for human consumption. Having at least one working paint tool is important because it validates the architecture and provides an example for other paint tools.

In case people would like to take a stab at hacking, it might be interesting to read the short paper I did on Krita's internals at:

http://koffice.kde.org/developer/krita/

Krita could actually be a pretty interesting project for someone interested in computer graphics -- the Krita architecture should support interesting things like 32-bit colour, CMYK and other colour models and interesting types of paint tools, packaged in an easy to use package.

My personal personal interest is in presenting natural media type paint tools in a package that's easy enough for an artist to sit down and start painting.


By Boudewijn Rempt at Fri, 2003/12/19 - 6:00am

32Bit color means 24RGB+Alpha or 32Bit per Channel?
Today you need at least 16Bit per Channel (RAW-Pictures of scanner and digicams)

Bye

Thorsten


By Thorsten Schnebeck at Fri, 2003/12/19 - 6:00am

No, no -- it should (but doesn't quite at the moment), support 32 bits per channel.

At the moment there's buggy CMYK(A) and decent RGB(A), both with 8 bits per channel, but all the colour model specific code is (or should be) encapsulated in colour strategies, and it's really easy to add new colour models. One day, when we have progresses a bit further, it will seem natural to add new colour models simply by adding a colour model plugin.

On the other hand, I am really not knowledgeable in this area. When starting on Krita I read four or five books on computer graphics and a few papers, but that's all, and my particular interest isn't in colour models -- even though I feel that I can abuse the colour strategy design to implement a 'wet & sticky' paint model or a 'wet' paint model. People who really know what they are doing might want to do a little gentle work on the current kis_strategy_colorspace_cmyk, for instance.


By Boudewijn Rempt at Fri, 2003/12/19 - 6:00am

Have tables improved in kword ? That was the single reason
I was not using kword, while I very much want to switch to Koffice
from Open Office which I am currently using.


By Asokan at Fri, 2003/12/19 - 6:00am

They have improved a little bit (e.g. it's easier to resize rows and columns, there are less painting bugs, and a few other changes I forgot), but table support in KWord still isn't optimum, to be honest. Still worth a try though?/


By David Faure at Fri, 2003/12/19 - 6:00am

I just finished compiling and installing it and I have to say, koffice is *much* improved since the last time I looked at it. KWord is actually usable for me now, table support is much better than it was (though not 100% yet). The only thing really missing is import and export filter being functional and comprehensive. (i.e. I exported a document to open office format and it didn't include any of the frames or the text in the frames.)

In any event, great job guys, keep it up DF.

Cheers,
Tormak


By Tormak at Fri, 2003/12/19 - 6:00am

Finally, someone gave it a try! I expected more people to be posting to this thread but I guess having to compile sources is a problem.


By KDE User at Fri, 2003/12/19 - 6:00am

Well, working on it, but it's being a bit awkward to compile...

(Compiling on a Fedora Core 1 system, current as of today's, 2003 12 19's, updates.)

cd ../../.. && \
/bin/sh /usr/src/redhat/BUILD/koffice-1.2.95/admin/missing --run automake-1.7 --foreign lib/kotext/kohyphen/Makefile
configure.in:43: version mismatch. This is Automake 1.7.8,
configure.in:43: but the definition used by this AM_INIT_AUTOMAKE
configure.in:43: comes from Automake 1.7.6. You should recreate
configure.in:43: aclocal.m4 with aclocal and run automake again.
make[4]: *** [Makefile.in] Error 1


By Graydon at Sat, 2003/12/20 - 6:00am

never mind, I'm dumber than bricks. Take the libtool patch out of the RPM sources for the 1.2.94 version and it (so far, still compiling) seems fine.


By Graydon at Sat, 2003/12/20 - 6:00am

The last time I tried to compile the 1.3beta, I got a lot of dependency errors and I couldn't fing the needed files. I'm running MDK9.1. Is there anything special I need to compile it?

Cire


By cirehawk at Sat, 2003/12/20 - 6:00am

Yes, for the word import/export filter you will need wv2. Unfortunatly there isn't a recent wv2 wv2-dev rpm for mdk9.1 (which is what I have). I had to get the wv2 sources and libwmf source and configure them on another machine since I ran into autoconf problems on 9.1, then compiled them on my machine. wv2 has a long list of dependencies, and if you don't need the ms word filters it is much easier. There was one other dependency which I don't recall, but I got it using urpmi (with the plf source iirc search on google for easy urpmi). The only other problem I had was compiling kdchart in kchart. It seems that a #define didn't get defined properly and I had to manually add #include to KDchartGlobals.h (something like that), and then add to the Makefile.am -I.. -I. in the C and CXX includes. After a few hours it finished and installed w/o further problems. It really is much better, esp kword, but unfortunatly kword also segfaulted on importing a really large (and fairly complex) msword document that I use a a benchmark of when I think a wp is up to snuff. That said, once there are solid word and openoffice import and export filters (and it's stable) I would strongly consider moving to kword permanently.

If you want I could make the compiled source tree available to you, for libwmf, wv2 and koffice-1.2.9 if you have a place for me to upload it, and have all of the required libs installed. (This would be for mdk 9.1).

Cheers,
Sheldon.


By Tormak at Sat, 2003/12/20 - 6:00am

If someone can reproduce the KDChart problem, posting the real compiler error message could be useful.

Have a nice day1


By Nicolas Goutte at Sat, 2003/12/20 - 6:00am

The problem (once I checked again) was actually 2 things. 1) config.h wasn't found b/c the directory wasn't included at compile time, and 2) in kdchart/KDChartGlobal.h there is:

#if defined(unix) || defined(Q_WS_MAC)
#include
#else
#define MINDOUBLE DBL_MIN
#endif

on my machine (Mandrake 9.1) for some reason unix wasn't getting defined and limits.h wasn't getting included. If you want more info contact me directly.


By Tormak at Sun, 2003/12/21 - 6:00am

The compile problems should be fixed now.

Have a nice day!


By Nicolas Goutte at Sun, 2003/12/28 - 6:00am

Thanks for the input Tormak. You described exactly the problems I had compiling. That would be great if you could provide the compiled sourse tree. Once I have that, what would I need to do (I'm not a programmer, so sometimes I'm not quite sure of some aspects of compiling)? Also, how large is it and I will find somewhere you can upload it.

Thanks again!
Paul.....


By cirehawk at Mon, 2003/12/22 - 6:00am

Well, it builds fine; dropped it into the same spec file as the Fedora 1.2.94 rpm, and with the patch files removed it builds nicely.

There do seem to be a few minor problems, though:

Build Messages (from running 'configure' without arguments)
--------------

Your libaspell is too old or not installed, I couldn't find aspell.h.
You must download aspell >= 0.50.2 See http://aspell.net/.
Spell-checking disabled.

But
rpm -q aspell
returns
aspell-0.50.3-16 (and there isn't an aspell-devel)

You're missing ImageMagick (>=5.5.2). krita will not be compiled.
You can download ImageMagick from http://www.imagemagick.org/

If you have problems compiling ImageMagick, please try configuring it
using
the --without-magick-plus-plus flag, the C++ API isn't needed for krita.

But
rpm -q ImageMagick
returns
ImageMagick-5.5.6-5 (and there isn't an ImageMagic-devel in Fedora, either.)

In Use
------

KSpread

So, how do I globally change the text font and font size of cells? Nothing seems to work but one cell at a time.

No print-to-fit? If it doesn't have that, it isn't a useable
spreadsheet for any business application, and I keep hoping this is going to show up.

Kword

KWord hit 86% CPU and held it until I closed the file when asked to load
a 1.7 MB rtf file. Which it displayed and handled fine, including
random jumps to halfway through. The individual pages wouldn't appear
in the frame display, though; the long list would appear with the click
and then vanish.


By Graydon at Sat, 2003/12/20 - 6:00am

KWord first: if you could make the file public, could you please add a bug report in http://bugs.kde.org (Personally, I know two big RTF files with tables that do not work.)

As for the libraries, I am going to look at what is searched.
Can you give the output of:
Magick-config --prefix

Have a nice day!


By Nicolas Goutte at Sat, 2003/12/20 - 6:00am

It would helpful to have the outputs of:
which Magick-config
Magick-config --version
which aspell
aspell --version

If you prefer to open a bug report for these configure problems, then please attach your config.log file. (I really mean to attach the file and not to copy it, so you can only do it after doing the bug report.)

Have a nice day!


By Nicolas Goutte at Sat, 2003/12/20 - 6:00am

The *-devel rpms don't exist anymore on Fedora ?
That's a huge improvement :)


By JC at Sun, 2003/12/21 - 6:00am