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.