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.


16 Responses to “ODF Interoperability: ideal vs. practice”

  1. Alex Says:

    I think Michael in Office Space summed it up the best: “Why should I change? He’s the one who sucks!”

    In other words, OpenOffice is clearly in the wrong here, so KOffice shouldn’t bend over backward to accommodate them. Also, there really needs to be a reference implementation of an ODF renderer. In fact, I think any file format standard should be required to have an open-source reference implementation.

  2. Javi Says:

    Don’t start hacking just to make it look like the reference app or you will end like web developers fighting to make all look similar along the different browsers.

    Follow the standard.

  3. Thijs Says:

    One big difference between MS Office and OO.org: While the users may expect compatibility with the de facto standard, the developers of OO.org probably also expect you and themselves to follow the official standard. Makes it less of a fight, I imagine.

    Also, ODF wasn’t that popular before it became an ISO standard. Nevertheless, a reference implementation should be there as soon as possible, I agree.

  4. albert Says:

    don’t implement a workaround or OOo will never change this bad behavior. It’s a bug and should be corrected (with a solution to correct the bad behavior) in OOo. Don’t introduce known bug or Microsoft and all people wanted to destroy ODF will take that as an exemple to not use it.

  5. Ian Monroe Says:

    They talked about this at the Linux Foundation Summit last year (I forget who). There’s a real need for an ODF test suite.

  6. Rob Weir Says:

    Good post. But I think applications have more flexibility to fix mistakes than with HTML. Why? Because ODF documents store metadata that indicate what application created them. So OpenOffice knows that a particular document was created in OpenOffice 2.4 versus one created in KOffice 1.6.3. So they could fix their bugs so new documents follow the standard, while old documents are rendered according to how OpenOffice 2.4 did it. We don’t have the problem of having millions of hand-edited HTML pages with no indication of whether they were meant for buggy I.E. or better I.E. or good Firefox. We should always be able to move forward and support the standard correctly.

  7. Fri13 Says:

    Which one is more important, follow the ODF-standard or the OpenOffice.org on this situation? I say, follow the ODF-standard. Thats why we wanted it that we can open files later correctly.

  8. Marcus Says:

    Your arguments are all correct but they leave users with the problem of having a lot of odf files written with OOo that look totally wrong in koffice. I for example have hundreds of documents which I need for teaching. That means I reuse them on a regular basis. I use headers a lot so that pupils know how many pages there are, what the topic is, etc. None of these documents are readable in koffice 2. I would really like to use koffice but I won’t rewrite every worksheet I have.

  9. Thomas Zander Says:

    There is a fine line between sticking to the perfect world and loosing relevance. Its easy to go to far and end up just getting the opposite result from what you really want.

    In this case its pretty clear cut in my mind; *all* existing presentations will have this flaw. I even think the majority of users will skip the koffice based powerpoint filters since they can use the open office ones which have better support.

    So if KOffice went the route of pointing the finger to OpenOffice and saying “sorry” to users the end result would basically be that KOffice refuses to work together with the other major partner in the ODF space.
    This totally defeats the purpose of using ODF in the first place; users want to be able to open docs they made in other ODF apps. If the two major apps refuse to work together out of principle, something really bad went wrong.

    I recently learned that its actually an internet standard which says “Be conservative in what you do; be liberal in what you accept from others.”

    This is where things get less black/white as you make them out to be; we want to work together with OpenOffice. Thats our main goal at this stage of ODF work since there are not that many presentation applications that generate ODPs 😉

    The secondairy problem here is that we need to find out the algorithm which OOo uses to determine those frames are actually supposed to be hidden and then implement that in KOffice. Naturally this should have no effect at all on what KOffice writes. Basically we should follow Postals law.

  10. g Says:

    I agree with most arguments that were given above by the responders. But I do not agree with copying buggy implementations in KOffice. If you start doing this, then within 10 years KOffice will end up like MS Office, namely being bloated software implementing all the bugs from historical versions of itself and other reference software (in the case of KOffice: OOo). The year 1900 bug is a bug that Excel inherited from Lotus which at that time (when Excel was still young) was the reference software for Excel; MS made the mistake of copying it and now they still have it. In my opinion the following should happen:
    – there must be an “Acid” test for ODF documents (this is a (set of) document(s) which similarly as for HTML display correctly if the implementation is correct) or an open-source reference implementation;
    – no bugs from other software should ever be deliberately introduced in KOffice;
    – there may be import filters in KOffice for ODF documents created in OOo which convert the buggy ODF code in correct code (for this it is of course necessary that KOffice always produces correct ODF code), but these import filters should be separate from the core ODF implementation in KOffice in order to keep the core implementation clean (and therefore maintainable in the long term).
    I know of course that you are the hackers and I am merely a user, so you decide how to implement stuff, but I would be happy knowing that you won’t make the same mistakes as MS.

  11. Jan Peter Says:

    I say every software must stick to the standard but provide a converter to the correct standard. Having OOo.org dictate isn’t bad, but it defeat the purpose of open standard by locking softwares into the same algorithm implementation. If KOffice could provide convertion into correct ODF and warn the user about the convertion, I think I can accept that flaw as a flaw not as a feature.

  12. slangkamp Says:

    @Thomas: The article I linked to explains why Postel’s law doesn’t work. If we do a workaround for everything, the real bug might never be fixed and every other ODF app has to do this hacks too.

    That’s exactly the problem of the browser developers they never said “sorry” and now they have a complete mess. Sure we will have to bend in some cases (And we already did), but I don’t think we should be compatible at all costs.
    It would defeat the purpose of using ODF for me if we implement support for everything, just to be compatible.

  13. David Tardon Says:

    Ad “no reference implementation”: There is odftoolkit.org. I don’t know much about it, so I cannot claim it’s complete and bug-free, but you can try for yourself.

  14. slangkamp Says:

    The ODF Toolkit only covers the the basic ODF loading/saving part which isn’t much of a problem. The interpretation of the loaded stuff is the problem.

  15. Elvis Stansvik Says:

    I think somehow the problem should be worked around, but that it should be clearly documented and separated as much as possible from the “on spec” loading code.
    I also think that if the user tries to load one of these buggy documents, he should be prompted about it and asked if he wants to re-save the document directly in order to fix it.
    But this is not an easy issue and you have to be careful, as other commenters have pointer out..

  16. Shaheed Haque Says:

    Follow the standard, not the buggy implementation, even if it is the de-facto reference.

    Postel’s law works in cases where the intended behaviour is (a) known and (b) ~canonical. The problem description suggests neither is true in this case.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: