ODF Plugfest

As you might have seen on the dot, I took part in the ODF Plugfest in The Hague last week. The goal of the workshop was to improve interoperability between the different ODF implementations. All of the big vendors like Sun, Microsoft, IBM or Google, lots of smaller ones and open source projects like KOffice and Abiword attended.

It was first time I was going to such a workshop and I had expected that there would be fights between the different vendors like it happened in some blogs before the workshop. It was a pleasant surprise for me that the athmosphere was very friendly and productive. It was really nice to meet other people projects/companys, put the competition aside for some time, work and drink some beer together.

There were many interesting details in the talks for example there was a proposal get OpenFormula out once it’s finished to be available for ODF 1.1 before ODF 1.2 is completely approved. Other important things were that there is much interest to get more SVG functionality into ODF, to have a consistent documentation of different implementations and of course Officeshots. Officeshots is a very important tool, as it allows to test documents with many different implementations on many different platforms. The only downside is that MS Office not available on Officeshots at the moment.

The interoperability testing in the afternoon was interesting. Everyone was sitting around a big round table and exchanged documents to test it in other apps. Here you can see how that looked like on tuesday (Photo by Doug Mahugh):

Over the two days many interoperability problems were found. One interesting issue we discussed on monday was a problems with some text appearing on the slide master in a presentation, a problem about that I wrote some time ago. What made this problem special that it’s probably the first problem that involves KOffice, OpenOffice and MS Office at the same time. A solution for the problem is currently investigated. In general the testing showed there is still a long way to go for everyone to get good interoperability.

Interestingly KOffice was pretty well-kown by the audience. I got many questions about the KOffice Windows port, unfortunately the windows packages lag a bit behind. We gained lots of test documents from the testing and have started to look into the issues. One problem when loading of embedded charts in files from MS Office has already been fixed.

Last but not least, I want to thank Michiel Leenaars, Fabrice Mous and everyone who organized this workshop. It was really great and I hope it will be repeated soon.

10 years of Krita

Today it’s ten years since Matthias Ettrich proposed the idea to write a full-features raster graphics editor, which started the development of the application that we know as Krita today. It’s interesting how Krita changed over the years and how different developers and their visions influenced the development process. Even though the original idea was to develop a replacement for the Kimp hack (which caused a controversial discussion at that time), development went into it’s own direction.

When I joined Krita in 2004, Boudewijn had just picked up development and the new vision was to develop a painting app. Soon more developers with other motivations joined the team and the other aspects like photo editing were added. A bit funny is that I’m neither an artist nor a photographer and I didn’t have a use for an image editing app at that time. I just wanted to work on an exciting project with a nice team, which turned out to be the case for Krita. Meanwhile I have become a lot more interested in computer graphics.

Since then a lot of progress has been made. This is a screenshot I made, just after I finished my second patch (implementing the first dockers) for Krita back in 2004. At this point Krita couldn’t do much more than the really simple painting.

From there development really took off and lots of features got added, leading to three releases with KOffice 1.4 (preview), 1.5 and 1.6. Krita also won the 2006 Akademy Award for Best Application. After that we entered the very long KOffice 2 development cycle, which brought lots of changes and new features to Krita. The good thing is that the next release will happen in a few days and the next versions will be out faster again.

So what will the next 10 years bring? It’s impossible to predict where it will go in the next years. Even though a larger vision of a painting app exists, Krita is mostly driven by the interests of it’s developers. I think there are enough ideas flying around at the moment to keep us busy for the next twenty years. Many things will be discussed on the next KOffice meeting in two weeks, including performance, brushes and collaborative editing.

KOffice GSoC 2009 projects

Google has announced the GSoC participants (the server went down just minutes after that) for this year and KOffice did get four great projects.

• Elvis Stansvik: Basic tables support for KWord
• Jeremias Epperlei: Enhance Formula Shape
• Dmitry Kazakov: New tile and mipmapping engine for Krita
• Lukáš Tvrdý: 3D brush for Krita

I’m really excited about that we could get so exciting projects again. This time I will be mentoring for the first time with Lukáš as student. It’s a bit funny that I will be mentoring before the code from my own GSoC project in 2007 is released with KOffice 2.0. As we had already expected we didn’t get as many projects as last year, but still we can be very happy.

This year it’s especially nice that also many smaller KDE apps could get projects. It really shows that KDE is a lot more than just the big projects like Amarok, KOffice or Plasma. Still many excellent projects had to be cut. Thanks to the admin team the selection process was much nicer this year.

Thanks Google.

ODF Interoperability: ideal vs. practice

As KOffice 2.0 is getting closer more and more people are testing it. If you have tested one of the beta releases you might have noticed that a lot of documents don’t look in KOffice like they look in OpenOffice. I’m aware that the KOffice ODF implementation doesn’t support all of ODF at the moment and that there are bugs, but in the last few months I noticed a totally different type of ODF problem is getting more and more important. The problem is that with the increasing number of ODF editors more and more issues show up where the documents are interpreted differently.

I saw an article on Joel on Software which explains the current situation and the way how got there pretty good. While the current ODF situation can’t be compared with HTML (Users don’t write the documents themself, so the number of incompatibilities is limited), the problems are similar. For both there was for a long time a one-to-one market with a domiant product, which defined a pragmatic standard. Now new players show up no matter if it’s Firefox and Webkit for HTML or KOffice etc. for ODF and an like the old claim “Everything has to look like in IE” we now have to deal with “Everything has to look like in OpenOffice”. Many users say that there is ODF which is an open standard and we just need to implement it and are compatible to OpenOffice. In theory that is correct, but in practice bugs and misinterpretations make it difficult (Though a it’s much better than between IE and Firefox).

Recently we had such a case: Bug 185354. Basicly the problem is that KPresenter shows some text in the background that’s not there in OpenOffice.

Looks like this in KPresenter:

How the original looks in Impress:

For the user the it looks like a bug in KPresenter, as the text wasn’t there when editing in OpenOffice and “appears from nowhere” in KPresenter. Actually it’s a bug in OpenOffice (scheduled for 3.2), where OpenOffice doesn’t mark the the text as placeholder so KPresenter loads it at normal text. There was a discussion if we add a workaround (which is hard to do, because we would need to implement the internal magic from OpenOffice) or if we should be more strict.

The biggest argument is that OpenOffice is currently dominant on the ODF market and we need to be compatible to get any user to use KOffice. At the same time we can see on HTML and the MS Office formats were that could lead. ODF supporters tend to laugh about things like the Excel year 1900 bug, but everyone should be aware that we could end up in similar cases if we don’t pay attention.

One problem is that there is not real reference implementation of ODF, so users can’t even decide which programm renders the document correctly. Also the OpenOffice team is doomed to keep everything the way it currently works, because changing anything would upset the users even if it’s better in the long-term (Fortunately this bug should be fixable without breaking anything).

There a few more problems like this, but I hope they will be solved sooner or later. Still ODF is the best format that’s available at the moment.

KPresenter PowerPoint-Filter the other way

At the moment the KPresenter PowerPoint-Filter is broken, which means that KPresenter 2.0 will not be able to import ppt files directly. Unfortunately many users have PowerPoint presentations around and every day a few million new ones are made. At the moment the only way to import ppt files in KPresenter is to use OpenOffice to convert them to odp.

On the other hand many users already have a very capable filter on their disk namely the one included in OpenOffice. Very often some user suggested to use the OpenOffice filters, but getting just the filter out of the apps is practically impossible. Yesterday vandenoever proposed on IRC that we could use OpenOffice in batch mode to convert the files. At first I found it pretty ridiculous as that filter would need the OpenOffice installed and it would be pretty heavyweight, but vandenoever insisted that he rather use that one than a faster but half-working native filter. So I decided that it could be interesting to give it a try.

So I started to hack a new ppt filter together. I found some example scripts on how to convert files with a headless OpenOffice. After three hours of glueing C++, bash and Python code together, I have now a working KPresenter ppt-Filter. The result is as expected: The filter is quite slow as it needs some time to start OpenOffice, convert the file and open it with KPresenter, but the result is really nice (though I only tested some files from Bugzilla, as I don’t have any ppt files around) and very convenient as I can just select the file in the file chooser and everything happens automatically.

The fiter is completely experimental and not publicly available (At the moment hard-coded for my system). Depending on the interest I might put it somewhere later.

Krush Day is over

On sunday the second KOffice bug day took place. Just like the triage last year, the this krush day was a huge success.

The bugsquad did an amazing job and found many bugs. Unfortunately I was busy finishing an university project, so I couldn’t take part in most of the fun. We expected to find many new bugs, but the amout of the found bugs surprised me a bit. For many apps there were more bugs discovered than in several beta releases together. It shows that the beta releases don’t get much testing. Especially Karbon, KChart, KPlato and even Krita get less testing than they need.

We also found many usability problems. As a developer you know pretty good what the app does and how it does something, so you don’t directly face the existing usability problems. It’s interesting to see how other people are using the app and what confuses them.

In case you still don’t know how to krush Krita, Elián Hanisch (m4v) made this great description:

The image is licensed under Creative Commons Attribution-Share Alike 3.0 and also available as Krita file (needs latest Krita trunk). The image is pretty cool as it’s the first real image, that I have seen, to make use of the new Krita shape layers.

Thanks to everyone who participated in the krush day. Your work helps to make KOffice 2 even better.

What a single bug report can do

Some bugs can last for a very long time. One of these bugs was bug 119150, it was added in 2005 and resisted several attempts to fix it. Additionally it was the last reported Karbon SVG bug, which motivated me to start a new attempt to fix it.

Fixing file import bugs is quite similar to archaeology, as you are digging through lots of data searching for some small detail that breaks the import. I was able to fix a smaller bug in the unit parsing which improved the import a bit. After investigating further I discovered that the style of groups in a defs element wasn’t correctly used, but I wasn’t able to fix it. So I filled a bug about it with a small testcase, which Jan could fix the same evening. Even after fixing the second bug the file wasn’t imported correctly, so I continued to search for the next bug. It turned out that the stlye of the use element wasn’t used. I wrote a provisorily fix which had some side effects. I send it to Jan, who was able to correctly fix it the day after.

Finally tuesday evening there was the magical moment were the file loaded perfectly for the first time and I could close the bug report after 1111 days.

To summarize: Due to the nice teamwork and the amzingly fast bug fixing by Jan, we were able to fix three SVG import bugs in 36 hours and could close the last reported SVG bug. There are now only 11 reported Karbon bugs (without the PS/EPS bugs, only three bugs).

Karbon now needs a lot more testing and there haven’t been many bug reports in the last time. For example you could open any .odg you have with Karbon and check if it looks correct. As the odf code is shared across KOffice, any bugfix will improve the situation for all apps.

Hello Planet KDE

After five years of being a KOffice developer, I finally started my first blog. I’m Sven Langkamp, living in Dortmund/Germany and I’m mainly working on Krita.

Here I will be writing about interesting developments in KOffice.