In the week of November 2nd I travelled to a little village in Italy called Orvieto. The reason for going to this lovely town is two conferences in a row.
The first one is the OpenDocument plugfest. The second is the openOffice.org conference, both of which were new experiences for me.

The ODF plugfest is a meeting where different implementors of a standard come together and come up with user scenarios and test how well they port between the implementations.
So you’ll see a document created in KWord being opened in OpenOffice.org and Microsoft Office and investigations started when the resuls are not as expected.

I did a presentation at the event of the progress made in the Qt (QTextDocumentWriter) and KOffice implementations of ODF and naturally the Maemo Office reader and last mentioned the Nokia sponsored officeshots.org node we are preparing.
The next day I had another presentation where I showed an interoperability issue with right-to-left languages. Several bugs were found in OpenOffice.org and MSOffice and a discussion followed to share the concepts of right-to-left text and (visual) text-alignment. These are tricky things so its important to all have the same ideas on how it should work.

The event had lots of talks, essentially making is clear we are not the only ones doing ODF and showing whats going on in this space. It was interesting to see how far MSOffice has come with ODF, and at the same time how much we need KOffice to become the big second implementor. MS said several times that for optimum interoperability they choose a solution that works better with OOo and not what the specification says it should do. Having a second independent implementation will benefit us all by keeping the standard authoritative, not the most popular implementation.

The event consisted of several interoperability scenarios, essentially manual testing of making a document, saving it in your app and adding it to the wiki. Then loading everyone else’s document and checking whats broken. Followed with an investigation how you can do better. Its a good way to keep the developers focussed so they don’t spent all their time on one feature and being bad overall. KOffice did pretty well here, except for the areas that were already marked as experimental anyway (like change tracking, which is work-in-progress).

Joining the OpenOffice.org conference was making me a bit uneasy, on going there I felt like I’m a spy in the opposite camp. How wrong I could be! The conference was indeed called OpenOffice.org but essentially is a collection of people interested in the open document format as well as the main implementation. There were lots of people from governments and other stakeholders that made clear they were just as interested in KWord as in any other ODF implementation.
This is a stark contrast to the usual events I go to where the majority of participants are volunteers or students. For I went through my business cards quite fast and wished I had brought more.
As usual I get a lot of good energy from these conferences, so many friendly faces, good talks and this being Italy, I had quite good food too

I’m always happy to get a face to a name I’ve been emailing with and nothing works better than a conference in a country where wine is as cheap as water during dinner.

KOffice2 is still a fresh set of office tools. We released the 2.0, called platform release, just 3 months ago and work continues to make the suite more stable and to add the minimum set of features people should be able to expect.

All KOffice community members are continuing to do an awesome job with many bugs being closed and lots of love going into all the applications. This means that the 2.1 release will already be much closer to being ready for the big crowds.
We got a little help now too. Nokia has packaged KOffice for Maemo 5 environment with a new UI for Maemo 5!, This means that KOffice can run in the new Maemo device(N900) . Just to clarify, this is not a commercial product of Maemo but is a contribution by Nokia to Open Source. The developed application will be made available for download in a typical release-early release-often. Bugs will likely exist in this version.

This is exciting news as KOffice will be available to a huge audience and Nokia has been helping to fix bugs and make MS-Office document support more robust.

Nokia has created a document viewer for the Maemo 5 platform (Fremantle) based on KOffice and uses the KWord and KPresenter applications to load and display word processor and presentation documents. The application uses a custom user interface specifically designed to fit in with the Maemo 5 style.

Part of the projects goals is to help KOffice mature its loading and rendering of MSOffice documents.

It is important to point out that all contributions to KOffice have been made directly inside the KOffice subversion repository. The KOffice document viewer for Maemo 5 will be shown for the first time at Maemo Summit in Amsterdam between October the 9th and 11th. This release is a bit unfortunately timed as the official KOffice2.1 release will likely be one or two weeks later making the Fremantle office use the release candidate at first.

I think its very exciting to have the hard work of all the KOffice community members be rewarded by having the document reader be based on our hard work. I’m very thankful to be working on the project and I’m looking forward to continued cooperation between Nokia and the KOffice community.

Its been some months since we released KOffice2.0.0, the first official release for the new platform KOffice2.
For common and certainly for advanced office users we made clear that 2.0 is missing features for them. What then, you may ask, is 2.1 going to change for them?
Well, here is what we are working on and what has been integrated into what will become the 2.1 release in a month or two.

Tables
Releasing a word processor without tables was pretty daring, and for 2.1 we did a lot of work to correct this. As part of the GSoC project we got Elvis Stansvik working on this for the whole summer. As this is part of KWord, I was the mentor and near the end we also got help from Casper Boemann. The end result is that KWord can show a huge set of tables based documents correctly. Its important to point out that this is ongoing work; creating new table cells or modifying the shape and look of a table is currently not possible.

Change Tracking
While editing a text document you can always undo your changes and get back to the way your document looked before. But what if you want to show the actual changes made right inside the current document? Or even better, being able to see what your colleague changed in the document over the weekend. This is what change tracking offers and this has been integrated just last week and it looks like we’ll have most of the expected features available in 2.1 thanks to the work of Pierre Stirnweiss. The most exciting part is that this lays the foundations for projects like collaborative editing.

Improved image handling
This has been detailed in another post already, so I’ll keep it short. For 2.1 the images handling has been made faster and we now are much smarter with memory usage so its possible to have image-heavy documents showing just fine even on memory constrained systems and devices.

Continued improvement in OpenDocument Format (ODF) support
ODF is still a huge specification and during the 2.1 time-frame there have been various teams working on testing and improving KOffice to become both better at writing correct and full ODF as well as reading other applications ODF documents. As ODF is a way to inter-operate between different application suites so its obvious that the way to get better ODF support is to collaborate on this front with others.
KOffice has been working at the front-lines with the industry big names for some time now. A recent example is the plugfest in The Netherlands last summer and the upcoming plugfest in Italy where KOffice is well represented.
An exciting initiative is the officeshots which renders an ODF document in all available office applications and shows the output. KOffice has been working with the OpenDoc Society to provide hardware and software support and make sure KOffice interoperability can be verified by everyone.

KFormula major improvements.
The formula editing component in KOffice has seen many upgrades since the 2.0 release. This means that all KOffice applications can now display and directly edit formulas. The GSoC project by Jeremias Epperlein has seen improvements specifically in rendering the formulas much more pleasing to the eye and the editing of a formula is well integrated into KOffice and quite easy to use.

Windows™
At the tagging of the beta1 all of KOffice compiled without problems on visual studio 2008 which significantly lowers the barrier to developer and end user adoption of KOffice. We are still looking for enthusiastic packagers and naturally developers on this platform to help improve the experience for end users.

MSOffice support
Still quite important for many is the ability to open MSOffice documents correctly and the major painpoints are one by one being addressed. Major things like importing text correctly, importing tables and importing images in presentations have been added for 2.1.

Having a picture in your text document is one of the simplest things you should expect a word processor to do. Having good looking images in your presentations, same thing. You should expect that to just work.
The fun begins when you take a look at that “just works” means. For instance, I can have a 1000 page document with one or more photos on each page. Those photos easilly take some 10Mb in memory if they are meant for printing. So obviously the simple solution of just having QImage objects is out.
Another problem that we see is when a user inserts a photo from his camera into the KPresenter presentation. Then scales it down to only be half the screen width. This means that we’ll effectively be showing the picture at some 15% of its original size. If we want to keep the viewing and moving of things around very nice and snappy, we can’t just scale the image on every repaint, that would be way to slow.

After a couple of weeks of coding we have a quite nice solution in KOffice. I added a KoImageData class which stores the actual image data and is able to dynamically create a scaled down version of that. The actual data we store is in many cases stored in a temporary file on the filesystem and transparently loaded when needed.
This has the directly noticeable effect that if you load a document with loads of images it will be much faster done, and with less memory used. The KOffice applications will no longer parse the image data on load. That will happen later.

My personal usecase is this; I would love to make a collage of loads of pictures of my friends and holidays. And I’d like to do that digitally. Now, when I create a new document in Krita or the Gimp that is full printing resolution of an A4. Then start loading the pictures as layers, it very quickly makes them crash or just get unusably slow.
My ideal solution is that I just start a KWord document where I insert a lot of these images into and I can scale, rotate and move them around very quickly. With hardly any suggestion that I’m manipulating huge amounts of data.
At printing time I’m printing actually to high-resolution images and the resulting PDF can be shown to the printer whom can print it at wanted resolution.
Expect this work work just fine in KOffice2.1

Likely I won’t make my second favorite feature for 2.1, this is to allow me to select an image and monitor it. So if I have an image in my KWord document that is using a file in my homedir called “photo.jpg” I can start my favorite application and change the image to be, for example, more saturated. On saving the image KWord would automatically show the updated image. Should be easy enough to add

Userbase is the wiki for application user information. It fills in a vital gap of information between traditional documentation and the usually too technical developer chatter. For at least KOffice it’s still in need of help, though. We want more tutorials for starters.
People like Anne Wilson have put a tremendous amount of work into userbase and I’m especially happy with the work on KWord she did. Userbase is for and by users, though. So we need help.

Tutorials are in my experience the best way to get a new user starting with the application, get them over the initial threshhold if you may. Its also the easiest way to teach that new useful feature you like to others that may want to use it too. Spread the joy kind of way.
With the Release Candidate of KOffice2.0 out I want to call users everywhere to install the packages from their distro and play around with it. When they find something that they think is a “gotcha”, write about it. Put up some screenshots and write a tutorial on userbase. You can then put them up on userbase.kde.org/KWord under the “Hints, Tips and Tutorials” part.

While its installing, or while your distro is working to get those RC packages to you we still need volunteers that can move and clean up tutorials that have been posted to blogs previously, before userbase became to be. Lets move all the content to one place and make it more useful for all. I put up a list of blogs I found here; Krita Talk

For people that are already quite accomplished in using software it sometimes is hard to come up with ideas on what would be a good tutorial subject. Since if you figure it out, it’s easy to forget how it took you some time to figure out how to do it. We need tutorials for very basic tasks, the kind that users have met and used in other packages, but also tutorials for introducing new ideas and now tools. I always enjoy reading the blog of Solveig Haugland who does write a lot of tutorials for OOo. As she is an experienced writer it would probably be good inspiration, both for content and level.

For an application suite like KOffice having good user support is pretty important. Having great user docs, tutorials etc all together on one place is in my opinion the way to go. For us its clear that userbase.kde.org is the place so all we need now is the more active of users to help us make it happen. For discussions on the topic you might want to go to the forums where developers and users hang out.

Last week the KOffice development hit a rather nice milestone; we reached a ReleaseCandidate. As usual this means we create a branch for the KOffice2.0 releases and we open up ‘trunk’ to new features.

With this branch point the 2.0 line of releases is naturally not going to stop being maintained so any fixes we make on trunk should be considered to be also committed on the 2.0 branch. And thats where it gets a bit sticky.
About half the KOffice developers have been using git-svn for some time now and at least I would rather like to continue using git and thus have the powerful git features available for moving patches between trunk and the 2.0 branch. The part that is sticky is that the mapping between git and svn is, and can not be, one to one. And the script does have some features for such situations but they don’t really work on an svn repo of KDEs format and size. Or, in short, you need to have a bit more git knowledge to set it up for our usage.

Goal; I want to have the ability to have 2 svn branches that I can update and commit to. I further want to be able to use git to move patches between them.
Solution; make a second git-svn checkout and use git remotes to let one know about the other.

#I assume you have a ‘koffice’ git-svn tree here already with the trunk version. To avoid any confusion lets rename it;
mv koffice koffice21
#Make a new checkout of the new branch;
git svn clone $KDESVN/branches/koffice/2.0/koffice -r 947933
# Again avoid confusion and make version explicit;
mv koffice koffice20
cd koffice20
#we create a remote
git remote add -f trunk ../koffice21

And thats it; now we can go into koffice20 and do things like
git svn rebase #sync with upstream svn
git fetch trunk #make visible new koffice21 commits
git log trunk/master
git cherry-pick trunk/master #get that commit from 2.1 and put it on 2.0
git svn dcommit

Naturally the normal git-svn-rebase and friends are still available on the koffice21 directory just like before it was renamed.

So I had to do some writing today and I thought, lets use KWord 2.0-Release Candidate for that. Eating your own dogfood and all that.
After a day of using the application in its default setup I am kind of pleased with it. Its obviously not an application that is going to replace any concurrence in its current state (the 2.0 release is aimed at integrators and basic users) but the actual typing of text and the usage of the basic features is good. I can write my docs in there.

That said, I had 2 crashes over the whole (10 hour) working day, both fixed in the RC, I fixed some loading/saving issues as well. And my todo list got quite a bit longer

Overall I think that the upcoming KWord2-release candidate is an enormous step forward from the latest beta. A speed of innovation and bug-crushing that I hope to see continue till the actual release (when its ready!). For people that can live without various features we had to omit in the 2.0 release I think the upcoming release will be a very cool basis platform for productivity applications.

ps. Yes, KWord will actually fully save and load the text, shapes etc that you can add in the app, in the upcoming Release Candidate. Finally! I know some of you have been asking about that