I know I’m repeating myself a bit. But as you know there’s a Wikipedia page about applications that support the Open Document Format and it gets quoted and linked to. A lot.
I linked to Peter Murray Rust yesterday, and one of the commenters on his blog also talks about the number of implementations.
OpenOffice.org is only one of the tools that can generate it, there are several others as well as various converters (e.g. SUN’s MS Office plugin, Clever Age ODF translator) available for MS Word users.
But folks, as of 2008-05-13 mid afternoon Toowoomba time, that Wikipedia page is not much help to people who might want to, like you know work on real documents. GoogleDocs, for example will throw away your styles if you happen to care about them. And why would you? It’s a web two-dot-oh world now what do we need with styles?
I’m going to get around to editing that page, but I’m not an expert so I have held off.
I just know that it’s not useful. Lots of things on that list don’t work with my ODF documents all created with applications derived from OpenOffice.org.
As part of my homework for when I do engage the page I went to the spec.
What does the ODF spec (v1.1) say about conformance? You need only read the first sentence of this extract, which I have highlighted for your convenience.
The OpenDocument specification does not specify which elements and attributes conforming application must, should, or may support. The intention behind this is to ensure that the OpenDocument specification can be used by as many implementations as possible, even if these applications do not support some or many of the elements and attributes defined in this specification. Viewer applications for instance may not support all editing relates elements and attributes (like change tracking), other application may support only the content related elements and attributes, but none of the style related ones.
Even typical office applications may only support a subset of the elements and attributes defined in this specification. They may for instance not support lists within text boxes or may not support some of the language related element and attributes.
So you don’t have to do anything in particular to claim to support ODF. Maybe just allowing the top level element would be enough?
We clearly need to add some detail to the Wikipedia page about who supports what specifically.
My working definition of support for ODF (the text format is actually what I care about) is people using our word processing templates to edit files interoperably with Writer and some other application. And you know what? There’s nothing outrageous in any of our templates, but the only applications that work are ones that are based on the original Star Office code base that spawned OpenOffice.org.
This is unsurprising. The file format was built around OpenOffice.org. Lots of people point out that nobody but Microsoft will be able to build an office suite that supports OOXML. People, this is the same process at work.
Let me tell you about a quick experiment I did. I looked up the bit in the ODF spec about lists. Apparently you can have a thing called a list-header at the start of the list.
A list header is a special kind of list item. It contains one or more paragraphs that are displayed before a list. The paragraphs are formatted like list items but they do not have a preceding number or bullet. The list header is represented by the list header element.
So I made a .odt using NeoOffice, put in a list using the default style List 1 saved it, unzipped it and added a list-header to the start of the list, then rezipped it and opened in NeoOffice. Hmm, well it does display, but the Writer interface seems to know nothing about list headers. The only way to create one seems to be outside of the application. Having a feature like this creates some very serious weirdness. You can load up a document with multiple paragraphs in the list header and they are preserved but if you try to add one then you just get a normal list item.
Now I know this is not quite in line with what I’m saying about the file format being largely derived from OpenOffice.org. I don’t know the history of this element but OpenOffice.org doesn’t support it in any useful way. Looks like something added by a standards committee raised on SGML with a clear idea of what makes a ‘good’ document format and not much consideration about what makes a usable word processor interface but that’s just a guess.
Lets talk about the formatting I got from my experiment. Is this what the spec really means?
See how the list header (Header 1) is indented? Not formatting I can imagine using. But it seems to be what the spec says. “The paragraphs are formatted like list items but they do not have a preceding number or bullet.”
How many of the ODF cheer squad have read the standard? Dealt with document interop issues? Me, I have only glanced at the OOXML spec and so I don’t go around telling people about how bad it is, but on the few occasions I have looked at ODF and tested support for various things in Writer I have found problems or lack of support in OOo. The good thing with OpenOffice.org, of course is that you can tell Sun about the bug and it will likely get fixed sooner or later, particularly if you can rally enough supporters to vote.
The bottom line is that if you want to work with ODT you have to check out whether the other applications are going to support the bit you want to use. I will get around to changing that wikipedia page to be more useful.
OK, so from your tests it appears that only 2 applications are meaningfully conformant with the ODF standard: OpenOffcie.org and StarOffice from SUN. That is sad and hopefully others will imporve in time, but I would like to point out that even this count of 2 is 2 more than the number of applications conformant with OOXML, which is exactly zero at this moment, see:
http://www.griffinbrown.co.uk/blog/PermaLink,guid,3e2202cd-59a3-4356-8f30-b8eb79735e1a.aspx
and
http://news.zdnet.co.uk/software/0,1000000121,39388229,00.htm
ZZ.
[How many of the ODF cheer squad have read the standard? Dealt with document interop issues? Me, I have only glanced at the OOXML spec and so I don’t go around telling people about how bad it is.]
The people who have glanced at the OOXML standard and have said how bad it is for interop as well as how broken it is are standards experts, not members of the public of laymen like yourself.
As far as interop is concerned the problem with OOXML is that nobody other than Microsoft can implement it properly because of its broken and incomplete nature. On top of that, its brokenness means that even Microsoft hasn’t been able to implement it – the OOXML produced by the latest versions of MS Office are incompatible with the OOXML standard Microsoft submitted to ISO.
[...] I linked to in my previous post about ODF supporting software is overly optimistic according to Peter Sefton’s blog. He demonstrates that only OpenOffice.org and StarOffice works properly with ODF while others have [...]
Now that’s hilarious. I’ve been using various programs that read-write ODF for a while, and had really good results. So far I’ve used Open Office on Windows, Linux, and Mac, KOffice on Linux, AbiWord, on Linux and Windows, and TextEdit on Mac, and had not problems at all moving files from one to the other.
So I get the impression that you don’t have a clue, since KOffice, TextEdit, and AbiWord don’t share the OOO code base.
@Wayne
I’d be interested to hear what kinds of documents work for you, but I can tell you that that for the documents I use which conform to a template that uses styles, including list styles (which is the only way in OOo to get consistent formatting for our purposes) KOffice does not work. Try it. KOffice does not support list styles at all so they get lost.
If you read the post I’m talking about degrees of support any data you could help out with would be very useful.
@Wayne again – just tried TextEdit on one of our test documents. No styles support and it doesn’t even render indented lists vaguely correctly. It may be good for you but it does not have the level of support I need for my work.
@wayne
Installed AbiWord on Ubuntu and tried it on a test doc. Indenting OK but does not respect ODT ‘restart numbering’ on lists. Some styles have come through OK but all list styles are in Standard style. Embedded photos not working. Document outline numbering attached to numbered heading style not showing.
Not suitable for use on ICE documents – clearly has shall we say ‘different’ ODF support from Writer.
Let me know what program versions you are using, and I’ll try it. For that matter email me a copy of the file you are using, and I’ll try that as well, I’m curious to see what happens.
[...] approach to text mining is necessarily pragmatic, which changes your outlook significantly (for detailed reasons why, read Peter Sefton’s blog). OOXML may be a flawed spec born of a standardisation [...]
I am a retired lawyer and former member of the OpenDocument Technical Committee who quit because of the anti-interoperability attitude of a voting majority of the TC. OOXML and ODF are about on a par as to interoperability. ODF has had the advantage of far fewer patent restrictions. OOXML’s interoperability warts have been thoroughly discussed by others so I will confine my discussion to ODF.
The ODF TC was chartered in 2002 to create a standard for a set of formats for the interoperable interchange of documents among competing applications. Sun’s OpenOffice.org XML format was chosen as the beginning point and Sun staffers were made the chairman and secretary. But Sun steadfastly shot down nearly all proposals over the years directed toward making the formats vendor-neutral.
OpenDocument interoperability is a complete and utter myth constructed on the widespread misconception that an open format is necessarily an interoperable format. The situation is only slightly better than with MS Office because OOo is distributed under an open source license that allows other developers to clone its code base. But it is necessary to achieve non-lossy interoperability that everyone exchanging documents be using the same version number of the code base. With other ODF implementations, you may achieve non-lossy interoperability if everyone involved is using the same application and version of it.
Whether you experience data loss when there is a mismatch in applications or version numbers in the exchange depends on what ODF functionality is invoked at each end of the round trip with a particular document. If an OpenOffice.org ODF document uses an ODF feature that has no counterpart in KOffice, opening it in the latter will will not result in the same processing of the document because there is no corresponding feature in KOffice to map to. The same issue exists when going between earlier and later versions of OOo or its clones.
There are many other interoperability issues in ODF. Here is my current list of interoperability check points that both ODF and OOXML fail except as noted in the list. If you need assistance with vocabulary, you will find a helpful glossary at http://www.universal-interop-council.org/glossary
* Full-featured editors available that do not generate vendor-specific extensions?
* Interoperability of implementations mandatory?
* Interoperability between different IT systems demonstrated?
* Profiles developed and required for interoperability?
* Methodology specified for interoperability between less and more featureful applications?
* Specifies conformity requirements essential to achieve interoperability?
* Interoperability conformity assessment procedure(s) formally established and validated?
* Document validation procedures valid?
* Fully specified interoperability framework?
* Vendor-specific extensions classified as non-conformant?
* Preservation of markup necessary for interoperability mandatory?
* XML namespaces for incorporated standards properly implemented? (ODF-only failure because Microsoft incorporated only one relevant standard, XML 1.0)
* Optional feature interop breakpoints eliminated?
* Scripting language specified for embedded scripts?
* Hooks fully specified for use by embedded scripts?
* Portable cross-platform? (OOXML-only failure)
* Adequate cultural and linguistic adaptability?
* IPR restrictions absent?
* Vendor- and application-neutral?
* Capable of converging desktop, server, Web, and mobile device editors and viewers? (ODF-only failure but OOXML only within the context of the Microsoft stack)
* Responsiveness to market requirements for interoperability?
If anyone should tell you that ODF is designed for interoperability or is an interoperable set of formats, they are either ignorant, deliberately disseminating disinformation, or both. I will close with the words of Thomas Zander, a member of the ODF Technical Committee and lead developer of the KOffice KWord application:
“One thing I have always dreamed to be possible is that when I write a doc in KOffice I can then open it in OOo to use that one feature that’s useful to me and then save it and continue in KOffice without loosing lots of data.
“Its still a dream, of course. Most features are lost on opening and saving it in OOo, but its a nice goal[.]”
http://lists.oasis-open.org/archives/odf-adoption/200709/msg00032.html
[...] This makes perfect sense for real-world testing. The results are interesting and unsurprising (to me, at least). Basically the best interoperability is between Microsoft Office Word and OpenOffice.org Writer [...]