“Is there any point to which you would wish to draw my attention?”
“To the curious incident of the dog in the night-time.”
“The dog did nothing in the night-time.”
“That was the curious incident,” remarked Sherlock Holmes.
— Silver Blaze by Sir Arthur Conan Doyle
A curious blog post from Brian Jones, looking at spreadsheet interoperability between Gnumeric and Apple’s new Numbers spreadsheet, using OOXML. Take a read there and come back and we can compare notes.
Did anything strike you as odd? What raised my eyebrows was the utterly trivial nature of the spreadsheet document that was tested. Typically an interoperability demonstration will be a little flashy, showing as much functionality as possible. But this one has no text attributes, only a single, default numeric style, no charts, no use of spreadsheet functions, nothing. Why bother? There is nothing in this spreadsheet that one could not easily have created in VisiCalc 25 years ago. So why is this simplistic document being used to demonstrate interoperability with OOXML? This seems very odd. Interoperability with a more substantial document would have been far more persuasive. So why didn’t they do that? Hmmm….
So I decided that I would give it a try, on my Windows XP laptop running Office 2007, OpenOffice 2.1 Novell Edition (giving it a test drive this week) and Gnumeric 1.7.10. Let’s see what really works.
First, let’s start with a more substantial spreadsheet document. I created the following in Office 2007, illustrating a variety of everyday features:
- numeric format
- simple text styles
- cell background fills
- cell alignment
- spreadsheet functions
- charts
- row widths
- worksheet password protection
- cell validation
- hyperlinks
- word art and shapes
- OLE embedding
Nothing fancy here, nothing that hasn’t been around in Office since Office 2000 or earlier. You could have done most of this in 1-2-3 version 2.3 a decade before that. I saved the document both in XLSX (OOXML) and XLS (legacy binary) formats. Both appeared identical as shown here:
Next, I tried opening the XLS file in OpenOffice. We see that it handled the file well:
The colors in the chart are clearly different, but I didn’t set any particular colors in the original, opting for the default. So this may just be an indication that the charts in OpenOffice have different default colors. As you can see from the above picture, everything else looks fine. I did verify that worksheet protections, cell validation and the hyperlink worked correctly. However, although the OLE embedding seems to be there, I was not able to activate it.
Next, I fired up Gnumeric to see how it would fare. I first tried the same XLS file which loaded and displayed like this:
What do we notice?
- Cell A7 did not format properly. It should be in long date format, but it is displaying in time format.
- Chart colors differ, but this is probably just a difference in defaults.
- Chart text is clipped in several instances.
- The OLE embedding failed to come through with correct metafile for display.
- Workbook protections and cell validation worked as expected.
- Hyperlink worked correctly.
- Arrow shape was dropped.
So, that is Gnumeric with a basic binary Excel worksheet. Since Gnumeric obviously supports this level of functionality, what would we expect to see when it loads the same document, but in OOXML format? See the image below for what I saw:
Hmm…OK… I think we hear the dog barking now. The OOXML import into Gnumeric is not really usable yet. In addition to the problems indicated above with the XLS import, we can add the following:
- None of the charts converted
- Worksheet password protection was lost
- The hyperlink is broken
- The OLE embedding is missing
- Cell validation is broken
- The word art is missing
Now a few points I wish to make concerning this. First I don’t want to have this taken as an attack on Gnumeric or those who work on it. Gnumeric is a fine spreadsheet with an impressive range of analytic features. The developers have done an outstanding job on it.
However, Microsoft points to Gnumeric as proof that OOXML can be implemented by other vendors. I suggest the jury is still out on this. 1-2-3 release 1.0a (1984) supported more functionality than Gnumeric does via OOXML. Note that even though there is no complete public documentation on the legacy binary formats, Gnumeric does a far better job at supporting them than it does with “standard” Ecma-376 OOXML and its 6,000 pages of documentation.
Now certainly, with much time and much effort, I’m sure Gnumeric will reach the point where it can read an OOXML document as well as it can read an XLS document. It might take another two or three years, but that day will come. But what benefit is that? All that effort will be spent writing code and testing to achieve practical results that Gnumeric already has achieved with the binary formats. This effort comes at the expense of other development activities such as adding features or fixing bugs. I hardly think that Jody wakes up in the morning joyed by the prospect of adding OOXML support to an application that is already compatible with billions of legacy Microsoft documents.
Similarly I have to scratch my head at OpenOffice and their announcement that they are adding OOXML support. As shown earlier, their support of the binary formats is already excellent. I guess that is why Microsoft is so eager to change their default formats. When a product like OpenOffice is able to effectively exchange documents with Office, it is too much of a threat to their Office revenue. So OpenOffice must now spend several person-years recreating this same level of interoperability, and the net result is that they will end up with the same capability they had before, but at the expense of forgoing work on new features. I wonder what Microsoft will do when OpenOffice catches up again in a few years? Hmmm…
(It would be interesting to examine out some of the other products that are said to support OOXML. Of the ones that support OOXML as well as the binary formats, how many of them also have OOXML support that is far worse than their binary format support? Is any editor vendor able to stand up and say that OOXML is a blessing to them because it allows higher fidelity interchange with Office than they were able to achieve with the binary formats?)
Everyone is in the same boat with this: KOffice, Corel, Google, IBM, anyone who has applications that work with Microsoft documents. We’re all faced with the prospect of significant expenses to rewrite our file format support with no net benefit to our customers. This is the toll we all must pay to Microsoft just for the ability to fight for the scraps their monopoly may leave behind. If Microsoft jerks their format around, we all must run and chase after it, reallocating resources away from feature work, becoming in the process less competitive in the marketplace, while Microsoft forges ahead with new features. They can easily repeat this game every few years, just to keep competitors busy. This is what a death spiral looks like.
Giving absolute control of a standard document format to a monopolist that is notorious for abusing their control of file formats in the past is insanity. It doesn’t take a Sherlock Holmes to figure that out.
