The Symphony Blog

After all the OOXML wrangling with the ISO standards committees last year, Microsoft has made a big deal of Office 2007 SP2 supporting ODF export/import:

The 2007 Microsoft Office system already provides support for 20 different document formats within Microsoft Office Word, Office Excel and Office PowerPoint. With the release of Microsoft Office 2007 Service Pack 2 (SP2) scheduled for the first half of 2009, the list will grow to include support for XML Paper Specification (XPS), Portable Document Format (PDF) 1.5, PDF/A and Open Document Format (ODF) v1.1.

When using SP2, customers will be able to open, edit and save documents using ODF and save documents into the XPS and PDF fixed formats from directly within the application without having to install any other code. It will also allow customers to set ODF as the default file format for Office 2007. To also provide ODF support for users of earlier versions of Microsoft Office (Office XP and Office 2003), Microsoft will continue to collaborate with the open source community in the ongoing development of the Open XML-ODF translator project on SourceForge.net.

However, now that Office 2007 SP2 is with us, it appears that with "much hard work and careful thinking, they have successfully achieved technical compliance but zero interoperability!".

Rob Weir has tested ODF compatibility between 7 different spreadsheet applications, including Google Spreadsheets, Lotus Symphony, OpenOffice and now MS Office 2007.  His results are revealing:

The new entry to the mix is Microsoft Office 2007 SP2, which has added integrated ODF support. Unfortunately this support did not fare well in my tests. The problem appears to be how it treats spreadsheet formulas in ODF documents. When reading an ODF document, Excel SP2 silently strips out formulas. What is left is the last value that cell had, when previously saved.

He goes on to report:

In the other direction, when writing out spreadsheets in ODF format, Excel 2007 SP2 does include spreadsheet formulas but places them into an Excel namespace. This namespace is not what OpenOffice and other ODF applications use. It is not the ODF 1.2 namespace. It isn't even the OOXML namespace. I have no idea what it is or what it means. Not every ODF application checks the namespace of formulas when loading documents, but the ones that do reject the SP2 documents altogether. And the ones that do not check the namespace try and fail to load a formula since it is syntactically different than what they expected. The applications essentially display a corrupted document that is shows neither the formula nor the value correctly. For example, a SP2 document, loaded in MS Office using the Sun ODF Plugin looks like this:



Similar corruption occurs when loading the Excel 2007 SP2 spreadsheet into KSpread, Symphony and OpenOffice. Google doesn't import the document at all.

Whilst Rob goes on to discuss why Microsoft might have ulterior motives for ensuring that its ODF meets the standard but fails on interoperability, he tries to be remain fair:

Of course, I am not that cynical. I was taught to never assume malice where incompetence would be the simpler explanation. But the degree of incompetence needed to explain SP2's poor ODF support boggles the mind and leads me to further uncharitable thoughts. So I must stop here.

Interesting reading...

In the meantime, if you need to ensure both ODF compliance and interoperability with other ODF applications, get hold of a copy of Lotus Symphony 1.2!