Archive for the ‘KOffice’ Category

ODP support for Okular

July 20, 2010

As you probably read on the Dot yesterday Okular doesn’t support much of ODF. I remembered that Jos had created the Slidecompare tool, so I got the idea to combine it with an Okular generator. It turned out that it’s pretty easy to combine the ends from both worlds. Okular offers a very nice API to write generators, which is almost an exact match to the KOffice one.

The generator currently supports only formats supported by KPresenter: ODP, PPT and PPTX. Currently only rendering is supported (so no search).

The generator is now in KOffice trunk. Even though it’s just 107 lines of code, it can make use of all the work that went into the KOffice import filters. I love integration!


KOffice font rendering again

July 9, 2010

A few months ago I blogged about font rendering in KOffice. The problem has been discussed and analysed a lot on the last KOffice meeting and the KOffice forum. The conclusion was that the problem can’t be fixed inside KOffice, but needs to be fixed in Qt. Since the problem is far from trivial and we don’t have developers with experience in that specific area, we rely on Nokia to fix the problem. Problem has been reported in two bugs here and here. Unfortunately the bugs have very low priority at the moment, so we need to make clear to Nokia how much these fixes are needed.

Everybody who is bothered about these rendering problems please vote on the two bugs I pointed out above.

In case these bugs don’t get fixedm a possible plan B would be to switch the rendering to use Cairo + Pango. Till then you can try to work around the problem as I have pointed out in my old blog post.

KOffice Mid 2010 meeting

June 20, 2010

Last weekend the KOffice Mid 2010 meeting took place at the Linuxhotel in Essen. As usual the meeting was pretty amazing. The Linuxhotel is a really great place for sprint: Many places to dicuss and hack (like the big lawn in front of the building), free drinks and good connectivity. All the food very food nearby, so we gained more time for being productive. Additionally it’s easy to reach from Dortmund which is also nice.

The main meeting on Saturday was divided into a big part where we discussed the general direction of the project and another part where we discussed specific technical problems. We spend quite a lot of time analysing the successes and failures of project. Boudewijn described lots of the things in the new Last week in KOffice, which is the new weekly development update similar to Last week in Krita.

Compared to previous meetings we are more filling remaining gaps than designing new things like flake. Even though there is still a lot todo, the progress of the last couple of months is very impressive. Mobile device are getting more and more important for KOffice especially for KWord, KPresenter and KSpread. It really shows that the whole work that went into redesign for KOffice 2 pays off.

In terms of technical discussion is good that the text-on-shape feature is now work in progress, which will allow text inside shapes needed mostly for KPresenter and Kivio. Another topic that I put on the agenda was the bad font rendering that KOffice suffers from. Jaroslaw and Sebastian have been digging through KOffice and Qt code to find a way to fix it. So far it looks like we will need to discuss is further with the developer from Qt Software to solve it.

Last but not least many thanks to everyone who help to make the sprint happen especially Alexandra and Inge for organizing it. And of course KDE e.V. and Nokia.

Kivio IRC meeting this saturday

February 11, 2010

Jos wants Kivio. Do you want an easy to use diagramming and flowcharting application with tight integration into other KOffice applications too? Then this is your chance. This saturday 13th February, 9 am UTC there will be a meeting in #koffice on with everyone who wants to help to get the first version of Kivio for KOffice 2 finished. It doesn’t matter if you haven’t done KOffice development before, just come around and see what you can do.

KOffice Sprint

December 2, 2009

Last weekend I have been attending the KOffice Sprint is Oslo. Like every other KOffice sprint it was really cool and we had lots of fun. It was the first time I visited Norway and I really liked it. Unfortunately these sprints are always so busy that you don’t really see much outside the office. I arrived friday night at the airport, where I met Jos and Jos. During the travel to the city I could try the new N900, which is really a cool device.

On saturday we had lots of interesting discussions about the lots of stuff. In contrast to the previous meetings many different things that are not directly technical issues in KOffice have been dicussed like the impending move to Git, release schedules, decision-making and the involvement of Nokia. Nokias testers did a huge amount of testing and I’m really looking forward to the development that will be done for KOffice 2.2. I got a N810 from Nokia and we had a lottery with five N900 as six month loan after dinner.

Back at the hotel we had a Krita meeting, where we discussed the plans for Krita 2.2. For 2.2 we are mainly focusing on stability and performance with the midterm goal to get Krita ready for the next Blender open movie. To reach this goal we are running a fundraiser to get Lukáš Tvrdý, famous brush wizard of Krita, working full time on Krita for three months to improve performance, stability and usability. See more information is available on the Krita website.
Click here to lend your support to: Help raise Krita to the next level and make a donation at !

On sunday morning we had a discussion about getting KOffice end user ready. There is much to do to and even though it’s remarkable what this small group of developers achieves we still need more developers. So in case you want to help making KOffice ready don’t hesitate to drop by on IRC or the mailing list and we will get something for you.

Big thanks go to Nokia, KDE e.V. and the organizers of this great sprint for providing the location, devices, food, accommodation and everything else that made this sprint such a great experience.

KWord font rendering

September 29, 2009

For quite some time I have been wondering what’s wrong with font rendering in KWord. I have seen KWord on other systems where the fonts rendering looked nice and sharp, but I couldn’t get the same look at my own system. The screenshot below shows how that looked.


The topic was discussed in the KDE forum and then in the KOffice IRC channel, where I finally got the right hint. The clue is changing the hinting style in the KDE systemsettings. This requires a some experimentation to find out which mode works best.

For me the change from full hinting to no hinting brought a great improvement as you can see below. The font in menu and toolbar changes a bit too, but that doesn’t bother me that much.


Maybe it’s possible to get even better rendering by flipping some secret switches, but so far I’m quite happy with the result.

The state of Kivio

July 27, 2009

As you might know Kivio, the KOffice diagramming and flowcharting application, hasn’t been released with KOffice 2.0. Since the release a lot of people asked on IRC how long it will take until Kivio will be released and what’s still missing for the release.

So what do we have so far? The current Kivio version in trunk consists of 223 lines of code. On the screenshot below you can see how it looks at the moment (with my own docker placement):


Of course the small code size doesn’t mean that it doesn’t have any features. Due to the high integration between the apps and the KOffice libs most of the features of KPresenter/Karbon are already available. For example load/save, inserting and arranging shapes, managing pages etc are done. Shapes can be rotated which was really missing in 1.6. Thanks to flake all shapes can now be interchanged seamlessy between Kivio and the other KOffice apps. At the moment there is also ongoing work to improve the connection tool.

What’s missing in Kivio? Most of the work to make Kivio usefull has been done KOffice libs. What Kivio needs now are developers to fill the missing gaps. The most important missing features at the moment are stencils sets as we had them in 1.6 and support for text on shapes. Unfortunately we are all already busy with developing the other KOffice apps and day jobs, so nobody is working on this at the moment.

ODF Plugfest

June 24, 2009

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.

KOffice GSoC 2009 projects

April 20, 2009

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

March 4, 2009

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.