Just like last year the KDE-family did provide us again a gsoc-slot to work on Improve ISO OpenDocument support (in KOffice, particularly in KWord). Not only did the number of mentors drastically increased but personally I also had the feeling the number of very good proposals did. To be allowed to read all of them was such exciting that I found myself spending hours over hours on the huge list reading lots of proposals again and again just for fun.

It is one case to walk through 7000 pages of rather technical documentation and to try to extract something useful out of it for a concrete question. It is another thing to look at the actual XML produced by the Microsoft Office 2007 suite.

For those that missed it, Microsoft recently released some of the specs relating to their office suite (http://www.microsoft.com/interop/docs/OfficeBinaryFormats.mspx).

Naturally, they probably aren't everything we'd like to have (various people have suggested that they aren't complete, and I'd be surprised if there wasn't something omitted, more likely because of incomplete records than because of deliberate omission - the PR downside to deliberate omission becoming public would be a disaster).

How's possible that most of my nightly builds I mention here, come from Berlin so far? Tasty food ensured by Trolltech or KDAB? Weißbier?

(gfx by mkbart, based on Oxygen icons)

In Berlin KDAB headquarters we have found all facilities needed for hacking. Awesome!

Anyway, here come another two KOffice apps running on Windows. Read on for tasty screenshots >>>

You can find more blogs from here at this space; labs.trolltech.com

(click to enlarge)

Yes, this is working copy of KWord 2.0 alpha running on KDE 4 under MS Windows, compiled during KDE-On-Windows meeting in Berlin. I must say local Trolltech's office is great environment for developing.

KWord in trunk (we recently got an alpha2 out) is not the same piece of software as it was in KOffice 1.x, its gotten such a makeover both internally as externally that its largely unrecognizable (in a good way). This also means that old known functionality may have problems due to it being new code.

When I woke up this morning I found this on #koffice

01:24 * astan zz.
01:24 <BCoppens> night
01:47 <astan> hm. is it possible to insert text frames in kword yet?
01:58 <astan> ok, i've just made my first commercial document using kword2 a receipt for this bicycle i'm buying for my book café.
01:58 * astan zz for real.

I guess that after compiling KOffice from svn and taking that extra half hour to do real work on it, KWord passed some sort of test

Some time ago I blogged about how KWord can now run around the outline of any shape you place in its text flow. One thing I have had on my TODO ever since was allowing a user to create a custom run-around outline that is separate from the outline of the actual shape we run around.

Yesterday morning I woke up and realized that actually its not that hard to do, and even while it was a feature for post-2.0 I sat down and did it anyway. Just 2 hours later I had a working prototype and this morning I dotted the I's and committed the stuff.

It works like this;

One of the things we wanted to do in KOffice is to use Krita when printing images from KWord. The reason for this are a couple, but the most important being that we want to have just one way to do printing of images and not waste time maintaining a more than one.
Naturally the option to let Krita convert the images to CMYK while printing (as soon as QPrinter supports that) sounds like a nice to have as well.

It turned out to be a bit harder than I first thought. The reason for that is due to the way that Flake works is that is separates processing and painting. The painting is reused for printing and painting always has to be as fast as possible; so no expensive calculations there. This keeps the interface snappy and user friendly. And I know you want that.

So, the problem is thus that painting is designed to paint the stuff we can paint right now; even if thats not the full content. The top couple of paragraphs of text, for example. And when the rest of the paragraphs have been properly layouted, then we'll just paint again. This concept works great on screen, but breaks down when printing. We don't want partial text on paper, we should wait until the whole text is positioned.

This effectively means we need someone to monitor the progress of a flake-shape and when its done with all the processing we can start painting. And this quickly means we need to do multithreading.

For that reason I added a KoShape::waitUntilReady() virtual method that a flake-plugin should implement if it has the problem that it can paint partial data. The idea there is that I call that method while trying to paint, and the method doesn't return until the shape is fully ready. After which I paint it to a printer. I implemented this for both the text shape and the krita-flake shape.

KWord now starts printing in a new thread and checks the quality of the images, loading the Krita shape plugin when it needs to. It will then drop back to the main-thread to actually do the painting of the shape (so shape-authors don't have to worry about multi-threading and locking). And it repeats this for each page.

It prints just great (and correct too!); while keeping the user interface snappy and responsive.

By now I wrote a nice collection of useful tools for multi-threading for KOffice. There is a KoAction which is the simplest interface you can use to make code run in different threads. There is a KoProgressUpdater which is a helper class to update progress of a task on a QProgressBar, from any number of threads. Naturally the new KoPrintingDialog this post was about. And we now have a KoShape::deleteLater() which is a thread-safe deletion of the shape. Required so we don't delete a shape that's just being painted in another thread, which would cause a crash.

Flake now doesn't just rock for easy painting and editing, it also is great for multithreaded applications and professional printing.

Some weeks ago KOffice alpha1 got tagged; but some balls were dropped and it never was uploaded to the ftp site. The good news is that even more new cool stuff is visible in the KOffice Alpha2 which will probably come out end of August.

One of the cool things in our Flake library are the ease with which you can make vector shapes. As Jan demonstrated by basically having a string of coordinates as a new template and coming up with a shape we call the Gearhead Jans blog. This addition is done in a C++ plugin right now; but we plan to add support so adding this kind of template can be as easy as pointing to a text file in the shape selector.

I rearranged my todo list a bit and did some required features as well as some features that were really scheduled for 2.1. But I just wanted to do them now. Sometimes you have to shake your fist at planning! Even if you are the only one actually overseeing the plan.

I added a feature that I think is pretty cool to have; its called text greeking. Basically when you paint text and the text ends up being really small (like a couple of pixels per character) you can't really read the text anyway. In this case I just paint a general block in the place of the text which naturally is quite a bit faster. This means that if you zoom out a lot that all those pages you see are still rendered quite fast.
I intend to use this concept in a page-selector; which can then paint the actual content in real time as its changed in the document without noticeable slowdown.

I have been seeing quite some good commits in KWord ODF loading from both Dipesh and Pierre Ducroquet. Going through the ODF testsuite I notice more and more testcases that KWord is passing. Chakka!

Another redesign I made in KWord has to do with images. We now lazily load images from disk; so you can have a document with tens of thousands of high quality images loading quite fast and taking not a lot of memory. And only when the images is shown the first time will it be loaded from disk for a preview. You can also set an image to be previewed in a low resolution to speed this up and conserve memory use. I'll be sure to make KWord print the high-res one when printing, naturally

Redesigns are useful when you have to write new code anyway; as I noted when I was going through our vast database of bugs for KWord I managed to close about 20 long open bugs that basically disappeared due to rewrites and redesigns at the lower level.

An example of such a thing is a new approach I took to footnotes. For those that don't know the term; its a often used concept of adding a marker in text, like a '1' and adding some text at the bottom of the page giving extra info. KWord used to implement the concept using frames, which means that if you have a footnote in a multi-column document you still have a full-page-width footnote at the bottom of your page. So I took a different approach and I embedded footnotes in the text-flake. Which means that the footnote is rendered at the bottom of the column in KWord. If you use the text-flake in an application like Krita or karbon you will now also be able to see the footnote. Which people will surely be able to see usages for. Creative people always do

Last item of today; Casper has started to do a rewrite of the ruler; which now looks like this:

Its still missing guide-lines and some other stuff it had in 1.x, but I believe he is working on that. Let us know what you think!