File format compatibility for common applications such as word processors and spreadsheets is worthwhile for everyone, whether you’re perfectly happy with Microsoft Office or you’re hankering for a freer or more Web-connected alternative.
After all, the more people who are able to not only consume but use and participate in the creation of our documents and spreadsheets, the more valuable those documents can be to us.
Fortunately, the state of file format compatibility across a range of different applications has come a long way in the past few years, as vendors have made progress toward addressing the two major pieces of the compatibility puzzle.
First, while no two applications ever will match up completely in functionality, applications meant to interoperate need to provide a core of common features-if there’s no analog in Suite A to your personal favorite Suite B feature, then you can forget about using the feature in your documents or expecting it to survive any round-trip editing scenario.
Second, there should be common ways to record the output of these core features, with standards clear enough-and broadly adopted enough-so that people can work together from the applications and platforms of their choice, with documents moving around with relatively little friction.
On the features front, OpenOffice.org has steadily blurred the lines between itself and Microsoft Office by adding and enhancing core features. For instance, OpenOffice.org’s recent 3.1 release boosts PowerPoint presentation compatibility significantly just by sharpening the on-screen graphics rendering of Impress.
On the format standardization side, Microsoft’s recent Office 2007 SP2 release represents a major step toward bridging file format compatibility gaps by adding support for OpenOffice.org’s default OpenDocument format. Microsoft’s maiden ODF support effort checked out well in the initial tests I put it through, but significant issues exist in Microsoft’s ODF implementation, such as in its handling of spreadsheet formulas.
Microsoft based its ODF work on current, ISO-blessed Version 1.1 of the standard, which didn’t go far enough in specifying formula handling to ensure the formulas would work the same as they moved from one ODF-based spreadsheet application to another.
Microsoft chose to deal with the lack of clarity around formulas in ODF 1.1 by stripping formulas out of ODF spreadsheets opened in Excel 2007 SP2. On the positive side, this tactic preserves whatever values inhabited the spreadsheet’s cells when they were last calculated, but that comes at the cost of being able to use the formulas-a major negative.
ODF adherents are claiming that Microsoft’s choices must have been the result either of incompetence or of ill will, and Microsoft is firing back with sort of an Eddie Haskell response about sticking to the letter of the standard.
It might have been helpful if Microsoft had targeted instead ODF 1.2, which is what OpenOffice.org uses by default (with 1.1 as an option) and which includes a great deal more detail concerning formulas. It’s understandable, however, that Microsoft would have preferred to target the current 1.1 standard over the as-yet-unratified Version 1.2.
Alternatively, I would have expected Microsoft to deal with confusing bits of the ODF specification by referring to existing implementations. How did OpenOffice.org deal with formulas in ODF 1.1? If nothing else, I would have liked to see the Excel team provide users with a pop-up dialog advising that their ODF spreadsheet formulas had been stripped out.
I intend to judge the success of ODF, and of Microsoft’s participation, by the code that comes out of it. ODF support in Office 2007 SP2 was a promising start, and I look forward to seeing what bug fixes Microsoft sends down its patching pipe and what Office 2010 will bring regarding ODF.
Executive Editor Jason Brooks can be reached at [email protected]