OpenDocument Format support not as great as the cheer squad keep saying
I know I’ve said this before, but I can’t help it. Just because an application has ‘Save as OpenDocument’ feature that does not mean it has useful OpenDocument support.
Benjamin Horst at SolidOffice points to Dispelling Myths around ODF (I don’t think all the myths really are myths (and why do people keep saying that ODF uses SVG? I reckon that’s a myth.) but I don’t have time to argue) I will confine myself to a comment on this bit. Benjamin writes:
My favorite section is where Erwin lists some of the prominent applications that use ODF as their default, or one of their primary, formats. These include KOffice, OpenOffice.org, StarOffice, IBM Lotus Symphony, Corel WordPerfect, Apple TextEdit, Google Docs, and plenty more.
I can’t comment on all of those, or the full list on Wikipedia but I do know these three things.
OpenOffice.org and StarOffice share a codebase – they’re really variants on the same application, while IBM Lotus Symphony also uses a lot of the same code, with the menus scrambled and no HTML export. At least they’re likely to interoperate.
Google Docs still has pretty useless ODT support. I just did another quick test and it still (a) produces awful HTML and (b) loses styles when you import ODT and (c) can’t export native Google Docs without significant weirdness.
The current shipping version of KOffice uses ODT in such a different way to OpenOffice.org that interoperability doesn’t work for anything but straight-ahead text. KOffice doesn’t have any implementation of list styles for example. The new version might be better but I have not figured out how to get a copy to try out without building it from source.
I wonder if anyone has looked properly at ODF interop, with a matrix of supported features and notes on how various import/export pairs work? From what I have seen, it would not be a pretty picture.
Hi PT,
Lotus Symphony is OpenOffice 1.1.4, which IBM took private while OpenOffice was dual licensed under SSSL-LGPL. In October of 2007, after the incredilbly disastrous ODF Interoperability WorkShop held at the OpenOffice Conference in Barcelona, Spain, IBM commissioned Sun to fix Lotus Symphony. This was done under the guise of IBM contributing to the OpenOffice source code.
One of the funny events at the ODF Interop Workshop was the line of Sun OOo/SO developers walking up to the Lotus Symphony demo station and popping the OOo 1.1.4 easter egg - then walking away.
KOffice has been a member of the OASIS ODF TC for five years now, and the interop between KOffice and OpenOffice might as well be zero. At some point in time people are going to have to start wondering why ODF interop is so bad - especially among contributing members of the OASIS ODF TC!
My own take is that ODF suffers from the same application specific problems that will forever doom OOXML. The presentation layers of each format are entirely reflective of the application specific idiosyncrasies, feature sets and layout engines unique to the originating applications.
There were three areas of ODF 1.0 - ISO 26300 that were woefully un specified: numbered lists, formulas and the presentation (styles) layer.
When Sun submitted what was then Open Office XML to OASIS, the specification was clearly an XML encoding of the OOo/SO binary dump. It was not the clean slate so many now claim it to have been. The clean up of the spec began with an effort to thoroughly document the different packages (content, styles, metadata, settings, manifest). Once fully documented, the idea was then to genericize any application specific findings. Sad to say, but five years have gone by and the presentation layer in particular has yet to be fully documented, let alone cleaned to the point of application independence.
As for OOXML? Forget it. They make no bones about the fact that OOXML’s entire reason for being is that it’s application, platform and vendor specific.
There was a point in time prior to the open sourcing of OpenOffice when Sun considered writing a browser for StarOffice. One of the browser requirements would have been (X)HTML - CSS 2.0 compliance. This led to an intense discussion as to whether or not OOo/SO could produce read-write (X)HTML - CSS 2.0 formats useful to the browser. The decision was that this work would require a total rewrite of the OOo/SO layout engine. So the browser project was dropped.
Think of the impact this decision has had. XML itself does not have a presentation layer descriptive. W3C materials suggest CSS, XSL or XSL-FO to fill that void. CSS in particular is perhaps the most portable and universally interoperable presentation layer in use today. This however would have been a difficult and costly choice for Sun.
Because of the legacy layout engine in OOo/SO, Sun choose a uniquely application specific presentation layer called “automatic-styles” when they moved to develop an XML format.
Having lived through the ODF process since it began in October of 2002, i would have to say that the right way of doing an XML interchange format would be to write a clean room spec based on generic document structures - and without application vendor participation. Generic elements might have cascading attributes that begin with basic “must have” metadata moving into ever more complex (and application specific) descriptives. This way an interoperability - interchange base can be used to service simple applications without compromising the rich, full featured needs of complex productivity environments.
This stuff isn’t easy. But if “interchange” is the purpose, then we can’t allow a handful of legacy application vendors dictate design. Once the basic spec is in place, invite the vendors to run test implementations with feedback comments.
Oh wait! That’s how the W3C designs formats. They follow without exception the first law of the Internet: Interoperability trumps everything, and is never compromised. Including demands for innovation. Including demands for application, platform and vendor specific needs.
~ge~
Comment by Gary Edwards — 2008-02-22 @ 12:44 pm
[…] claims to support ODF over OOXML but Google Docs has awful ODF support I wrote last week about the way supporters of the OpenDocument Format talk-up the number of supporting applications, […]
Pingback by PT’s blog » Blog Archive » Google claims to support ODF over OOXML but Google Docs has awful ODF support — 2008-02-27 @ 10:16 am
[…] […]
Pingback by PT’s blog » Blog Archive » Some comments on OOXML, ODF and Microsoft Word — 2008-05-12 @ 11:30 am
[…] about ODF support are typically meaningless 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 […]
Pingback by PT’s blog » Blog Archive » Claims about ODF support are typically meaningless — 2008-05-13 @ 4:33 pm