decoration decoration
Stories

GROKLAW
When you want to know more...
decoration
For layout only
Home
Archives
Site Map
Search
About Groklaw
Awards
Legal Research
Timelines
ApplevSamsung
ApplevSamsung p.2
ArchiveExplorer
Autozone
Bilski
Cases
Cast: Lawyers
Comes v. MS
Contracts/Documents
Courts
DRM
Gordon v MS
GPL
Grokdoc
HTML How To
IPI v RH
IV v. Google
Legal Docs
Lodsys
MS Litigations
MSvB&N
News Picks
Novell v. MS
Novell-MS Deal
ODF/OOXML
OOXML Appeals
OraclevGoogle
Patents
ProjectMonterey
Psystar
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v IBM
SCO v Novell
SCO:Soup2Nuts
SCOsource
Sean Daly
Software Patents
Switch to Linux
Transcripts
Unix Books

Gear

Groklaw Gear

Click here to send an email to the editor of this weblog.


You won't find me on Facebook


Donate

Donate Paypal


No Legal Advice

The information on Groklaw is not intended to constitute legal advice. While Mark is a lawyer and he has asked other lawyers and law students to contribute articles, all of these articles are offered to help educate, not to provide specific legal advice. They are not your lawyers.

Here's Groklaw's comments policy.


What's New

STORIES
No new stories

COMMENTS last 48 hrs
No new comments


Sponsors

Hosting:
hosted by ibiblio

On servers donated to ibiblio by AMD.

Webmaster
Does MS Office SP2 With ODF Support Really Work? Test Results Point to No. - Updated 3Xs
Monday, May 04 2009 @ 12:14 AM EDT

I tried the updated Microsoft Office 2007 SP2, which supports ODF, or says it does. I created a document in Office 2007 SP2 and saved it as ODF. I got an ominous Microsoft warning that if I persisted, I might lose some formatting -- "Document [name] may contain features that are not compatible with this format. Do you want to continue to save in this format?" -- but it saved the document when I clicked Yes. I reasoned that OpenOffice, which I intended to use to test the result, does have the features I wanted. I had included one footnote, a photo, and a text block, all of which OpenOffice can do, but when I opened the saved document in OpenOffice, none of it looked right. You couldn't read the footnote at all, because it's cut horizontally in the middle of the text. You can see it's there, but you can't make out the words.

I thought most of the problems, and there were others, might be my fault though, because I've never used Office 2007 before, since I don't own it, and I found it very confusing. Because I don't own Office 2007, and I had limited access time to test on someone else's, I looked around to see if anyone else was reporting results in the new SP2. I asked Groklaw members if they had tried it out yet and how it worked for them. A Groklaw member, Dobbo, did a test working on a spreadsheet with a client, and his experience was also a failure.

It turns out Rob Weir also did some tests of spreadsheets, and it's not just me and Dobbo, and it's not just Word documents. If you are a government trying to decide if now's the time to adopt OOXML, because ODF is now allegedly supported, you probably want to read his Update on ODF Spreadsheet Interoperability. He compares all the options, which he tested a couple of months ago, OpenOffice, Google Docs, Clever Age, Sun's plugin, KSpread and Symphony, adds in the new Office 2007 SP2, and makes the comparison. I think it's fair to say that SP2 does worse than any of the others, or at best they fail equally in some categories. Clever Age actually did better on the tests than Office 2007 SP2. Why? What could possibly explain that?

Why would Microsoft be worse than the others? Here's a bit on that from Weir's article:

The new entry to the mix in this round is 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.

This can cause subtle and not so subtle errors and data loss. For example, in the test document I presented above, the current date is encoded using the TODAY() spreadsheet function. If the formulas are stripped, then this cell no longer updates and will return the wrong value. Similarly, if Maya tries to continue her ledger of expenses by copying the formula cells from column E down a row, this will cause incorrect answers, since there is no longer a formula there. In general, SP2 converts a spreadsheet into a "table of numbers" and any calculation dependencies are lost.

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. Not every ODF application checks the namespace of formulas, but the ones that do reject the SP2 document altogether. And the ones that do not check the namespace try and fail to load a formula that is syntactically different than what they expected and they essentially display a corrupted document.

What he found is that if you create a spreadsheet in Microsoft Office 2007 SP2, it won't render properly in Google Docs, OpenOffice, KSpread, Symphony, or with the Sun Plugin. If you create the document in OpenOffice and then try to read it in Microsoft Office 2007 SP2, you can't do that either. He found that spreadsheet interoperability is actually worse now than when he last tested:
I must admit that I'm disappointed by these results. This is not a step forward. This is a step backwards compared to where we were two months ago. Spreadsheet interoperability is not hard. This is not rocket science. Everyone knows what TODAY() means. Everyone knows what =A1+A2 means. To get this wrong requires more effort than getting it right. It is especially frustrating when we know that the underlying applications support the same fundamental formula language, or something very close to it, and are tripped up by lack of namespace coordination. Whether it is accidental or intentional I don't know or care. But I cannot fail to notice that the same application -- Microsoft Excel 2007 -- will process ODF spreadsheet documents without problems when loaded via the Sun or CleverAge plugins, but will miserably fail when using the "improved" integrated code in Office 2007 SP2.
If you or they say, "It's ODF's fault," why, then, is everyone else able to make it work better than Microsoft, which is what Weir found? They funded Clever Age, after all, didn't they? So why would Clever Age work better than Microsoft's support for ODF in Office? It makes no sense. I remember the tricks to make sure DR DOS and WordPerfect didn't work quite right. Is this something similar? Incompetence? What? In any case, Weir tells them how to fix it, if it's that. But here's what I learned: you can be conformant to a standard and *not* interoperable at the same time. Maybe someday an EU Commission investigation can figure out if it's deliberate or not. Meanwhile, we still can't interoperate with Microsoft Office 2007 SP2. So if you are going to send me a document, until Microsoft offers actual interoperability, please don't use that to create your document or I might not get your complete message. Drop down to saving as a .doc or the other older versions of Excel or whatever for my sake and for the sake of others who don't use Microsoft software.

Here's Dobbo's experience:

Microsoft Office 2007 SP2 OOo Compatability via ODF
Authored by: dobbo on Saturday, May 02 2009 @ 09:11 AM EDT

In a past Groklaw article PJ was asking about interoperability between Microsoft's Office suite and OpenOffice now that MS-Office supports ODF. This is also of interest to me as I am current working on a project that has to process data coming from an Excel spreadsheet, and an ODF dump from Excel might be advantageous to me.

As my client uses Excel I pointed him at the upgrade which he downloaded and installed. His current Excel spreadsheet is a masterpiece of complexity: hidden sheets and cells, lots of validation macros and so on and so forth. But I wondered just how interoperable with OOo it would be.

It wasn't!

For a start it doesn't look the same, or so I am told. I don't have Microsoft here, just Linux so I have to use OOo to view the spreadsheet. But my client reported that OOo running on his computer didn't render the sheets the same.

But the bigest problem (for me at least) was the fact the the macros didn't work. Here is a simple example:

Output from MS-Office: =COUNTIF(A23:A922,"S")+COUNTIF(A25:A924,"SS")
The problem is the Microsoft has used commas as argument separators and OOo uses semicolons.

Actually, as Weir shows, it's a much bigger problem, and not just for OpenOffice. And the patch must come from Microsoft. Clearly they could make spreadsheet interoperability work if they wanted to, since others already are.

Dear Microsoft, could you please do something about this? It's just code, which means it can be fixed. But your code is proprietary, so we can't fix it. Only you can. Like the old song says, could you please put on some speed? Others like Google Docs seem to be able to do ODF spreadsheets. Why can't you? No doubt there will be improvements, but when?

Meanwhile, folks, don't be fooled into thinking that life in the OOXML-ODF interoperability universe is now suddenly a breeze. It's not.

Here's the result of my first mangled attempt to open a Microsoft 2007 SP2 document, saved as .ODT and opened in OpenOffice, and yes, I'm blushing:

I feel just like that squirrel when trying to interoperate with Microsoft. And while I openly confess that I didn't know what I was doing in Office 2007, the footnote did work, up to a point, as far as my input was concerned. The cutoff problem isn't from me, after all. I also don't see any number, and it didn't show in the main text that there was a footnote, probably because some of the text disappeared, maybe under the photo, but all of that could be me not being an expert. But you know what? I'm pretty sure that I am no more stupid than any other normal user out there trying to make things work. It just doesn't seem to work.

[ Update: Here's a quote from Microsoft's press release a year ago in May, when it announced SP2:

Microsoft recognizes that customers care most about real-world interoperability in the marketplace, so the company is committed to continuing to engage the IT community to achieve that goal when it comes to document format standards. It will work with the Interoperability Executive Customer Council and other customers to identify the areas where document format interoperability matters most, and then collaborate with other vendors to achieve interoperability between their implementations of the formats that customers are using today.
Promises, promises. Real-world interoperability. In my lifetime, you think? - End update.]

[Update 2: Microsoft's Doug Mahue tells us the meaning of the warning message when you save as .odt like this:

I’ll get a message warning me that my document may contain features that aren’t compatible with this format, because ODF can’t represent 100% of the things we can do in Word.
Heh heh. And evidently vice versa. - End update 2.]

Update 3, Wednesday May 6: Unbelievably, Microsoft's Gray Knoulton has posted a response, Rethinking ODF Leadership, suggesting that Weir be replaced as co-Chair of the ODF Technical Committee because of his article:

I'm not saying Microsoft (or anyone) should be the chair instead, but I am saying that Rob is unfit as a leader given his inability to separate his personal venom from his role as a leader in driving the standard forward. It seems like a better approach to empower people on the ODF TC who have a long-term view of the need to enable interoperability, and to move those with more short-term vendor-oriented agendas to the side.
And so the Microsoft effort to control ODF continues. Unbelievable reaction. Why don't they just fix their software? Comments here, including Weir's response. - End update.]

The chart is far more vivid on Weir's blog than here, because he makes the entire cell red, not just the word 'Fail'. This will certainly give you the big picture, though, and I want a permanent record of this information in Groklaw's archives.

****************************

Update on ODF Spreadsheet Interoperability

~ Rob Weir, An Antic Disposition

A couple of months ago I did a blog post about interoperability of ODF spreadsheets, the theory and practice of it. In that post I looked at the then current ODF implementations, including:

  1. Microsoft Office 2003 with the Microsoft-sponsored CleverAge Add-in version 2.5
  2. Google Spreadsheets
  3. KOffice's KSpread 1.6.3
  4. Lotus Symphony 1.1
  5. OpenOffice 2.4
  6. Microsoft Office 2003 with Sun's ODF Plugin
I showed what worked, what didn't and made some suggestions on how this could be improved. Essentially, I found only two notable failures, when the CleverAge Add-in for Excel loaded KSpread and Symphony documents. The other scenarios I tested were OK:



Created In






CleverAge
Google
KSpread
Symphony
OpenOffice
Sun Plugin

Read In


CleverAgeOK
OK
Fail
Fail
OK
OK

GoogleOK
OK
OK
OK
OK
OK

KSpreadOK
OK
OK
OK
OK
OK


SymphonyOK
OK
OK
OK
OK
OK

OpenOfficeOK
OK
OK
OK
OK
OK

Sun PluginOK
OK
OK
OK
OK
OK



I lot has happened in the past two months. Since I did that original analysis, we've seen the following applications updated:

  • CleverAge has released version 3.0 of their Add-in for Excel.
  • OpenOffice 3.01 is now out and in wide use
  • Symphony 1.3 is in beta
  • The Sun Plugin is now at version 3.0
  • Microsoft Office 2007 SP2 has been released, with integrated ODF support
  • KOffice 2.0 RC 1 is now out
I haven't been able to get the release candidate of KOffice installed, so I'm still including KSpread 1.6.3 in my tests, but for the rest I have created new test files in each editing environment, saved them to ODF format and then loaded the resulting documents into each of the other editors. So 42 different test scenarios. First I'll tell what I tested, then give you the table of results, and finally some observations and recommendations.

The test scenario I used was a simple wedding planner for a Maya, who is getting married on August 15th. She wants to track how many days are left until the wedding, as well as track a simple ledger. Nothing complicated here. I created this spreadsheet from scratch in each of the editors, by performing the following steps:

  • Enter the title in A1 "May's Wedding Planner" and increased font size to 14 point.
  • Enter formula = today() in A3 and set US style date format if necessary
  • Enter the date of the wedding as a constant in cell A4, also setting date format if necessary.
  • Simple calculations on cells A6-A8, to calculate days, weeks and months until the wedding
  • A11 through E16 is a simple ledger of the kind that is done thousands of times a day by spreasheet users everywhere. Once you have the formula set up in column E (Balance= previous balance + credits - debits) then you can add more rows and simply copy down the formula to the new row.
The resulting spreadsheet looks something like this:




Feel free to download a zip of all of the spreadsheet files. The file names should be self-explanatory.

Here is what I found when I tested the various scenarios:



Created In







Google
KSpread
Symphony
OpenOffice
Sun Plugin
CleverAge
MS Office 2007 SP2

Read In


GoogleOK
OK
OK
OK
Fail
OK
Fail

KSpreadOK
OK
OK
Fail
Fail
OK
Fail

SymphonyOK
OK
OK
OK
OK
Fail
Fail


OpenOfficeOK
OK
OK
OK
OK
OK
Fail

Sun Plugin
OK
OK
OK
OK
OK
OK
Fail

CleverAge Plugin
OK
OK
OK
OK
Fail
OK
OK

MS Office 2007 SP2
Fail
Fail
Fail
Fail
Fail
Fail
OK


So what is happening here?

CleverAge appears to have heeded the advice from my earlier blog post and now correctly processes KSpread and Symphony spreadsheets. This is great news and they deserve credit for that work. But this is a small bit of good news in a table that now shows awful lot of red. Let's see if we can figure this out.

First, some combinations that worked previously, when I tested two months ago, are now not working.

  • Symphony 1.3 beta hangs when loading the spreadsheet created with the CleverAge 3.0 ODF Add-in. Symphony 1.1 also hangs when loading that same spreadsheet, but both versions of Symphony work fine when loading the CleverAge 2.5 spreadsheet . The CleverAge document appears to be valid, so my guess is this is a bug in the Symphony 1.3 beta. I'll pass this document on to the Symphony development team.
  • KSpread 1.6.3 fails to process OpenOffice 3.01 documents. KSpread had no problems with OO 2.4 documents. The problem appears to be that OpenOffice 3.01, by default, writes out documents according to the ODF 1.2 draft which puts formulas in the OpenFormula namespace. But KSpread is expecting them in the legacy namespace. So formulas are dropped.
  • In a similar way, Sun's new ODF Plugin writes out documents according to the ODF 1.2 draft. KOffice is unable to handle these files. This also causes problems for Google Spreadsheets and the Microsoft/CleverAge Plugin for Excel, which report errors "We were unable to upload this document" and "The converter failed to open this file".
The new entry to the mix in this round is 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.

This can cause subtle and not so subtle errors and data loss. For example, in the test document I presented above, the current date is encoded using the TODAY() spreadsheet function. If the formulas are stripped, then this cell no longer updates and will return the wrong value. Similarly, if Maya tries to continue her ledger of expenses by copying the formula cells from column E down a row, this will cause incorrect answers, since there is no longer a formula there. In general, SP2 converts a spreadsheet into a "table of numbers" and any calculation dependencies are lost.

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. Not every ODF application checks the namespace of formulas, but the ones that do reject the SP2 document altogether. And the ones that do not check the namespace try and fail to load a formula that is syntactically different than what they expected and they essentially display a corrupted document. For example, a SP2 document, loaded in MS Office using the Sun 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.

I must admit that I'm disappointed by these results. This is not a step forward. This is a step backwards compared to where we were two months ago. Spreadsheet interoperability is not hard. This is not rocket science. Everyone knows what TODAY() means. Everyone knows what =A1+A2 means. To get this wrong requires more effort than getting it right. It is especially frustrating when we know that the underlying applications support the same fundamental formula language, or something very close to it, and are tripped up by lack of namespace coordination. Whether it is accidental or intentional I don't know or care. But I cannot fail to notice that the same application -- Microsoft Excel 2007 -- will process ODF spreadsheet documents without problems when loaded via the Sun or CleverAge plugins, but will miserably fail when using the "improved" integrated code in Office 2007 SP2. This ain't right.

There would be a lot less red on the above table if two simple changes were made:
  1. Sun should write out formulas in ODF 1.1 format, using the "oooc" namespace prefix that the other vendors are using. Remember, the other vendors are using that namespace specifically for compatibility with OO's ODF documents. This is the current convention. To unilaterally switch, without notice or coordination, to a new namespace, is not cool. When ODF 1.2 is an approved standard, then we all can go there in a coordinated fashion, to cause users minimal inconvenience. But the above table clearly shows the confusion that results if this move is not coordinated. I know OO 3.01 has an option to save in ODF 1.0/1.1 format. But this should setting should be the default, IMHO. I'm not sure if the Sun Plugin has a similar configuration option.
  2. In addition to writing out compatible formulas as per the above comments on the Sub Plugin, Microsoft should remove the code in SP2 that causes it to reject every other vendor's spreadsheet documents. It looks very bad to cause this much data loss and their intentions in this area could easily be misinterpreted. Give the user a warning if you need to, but let them have the choice.
Finally, let me try to anticipate some of the counter-arguments which might be raised to argue against interoperability, and debunk them.

First, we might hear that ODF 1.1 does not define spreadsheet formulas and therefore it is not necessary for one vendor to use the same formula language that other vendors use. This is certainly is true if your sole goal is to claim conformance. If your business model requires only conformance and no attempt at achieving interoperability, then I wish you well. But remember that conformance and interoperability are not mutually exclusive options. You can be conformant to the standard and also be interoperable, if you use the legacy formula namespace and syntax. So this isn't a question about conformance at all. It is a question about interoperability and whether you do what is necessary for that as well.

We might also hear concerns that supporting other vendors' ODF spreadsheet formulas cannot be done because this formula language is undocumented. Of course, the irony here is that the formula language used by OpenOffice (and by other vendors) is based on that used by Excel, which itself was not fully documented when OpenOffice implemented it. So an argument, by Microsoft, not to support that language because it is not documented is rather hypocritical. Also, the fact that the Microsoft/CleverAge add-in correctly reads and writes that legacy syntax shows not only that it can be done, but that Microsoft already has the code to do it. The inexplicable thing is why that code never made it into SP2.

We'll probably also hear that 100% compatibility with legacy documents is critical to Microsoft users and that it is dangerous to try to write Excel documents into compatible ODF formulas because there is no guarantees that OpenOffice will interpret them correctly and give the right answer. But we should note that fully-licensed Microsoft Office users have already been creating legacy documents in ODF format, using the Microsoft/CleverAge ODF Add-in. These paying users of Microsoft Office will now see their existing investment in ODF documents, created using Microsoft-sanctioned code, get corrupted when loaded in Excel 2007 SP2. That is the shocking thing here, the way in which users of the ODF Add-in are being sacrificed. Why are paying Microsoft customers who used ODF less important than Microsoft customers who used OOXML?

If you are cynical, you might observe that if SP2 allowed Microsoft/CleverAge ODF Add-in formulas to work correctly, then SP2 would need to allow all vendor's formulas to work, since the other vendors are using the same namespace. The only way for Microsoft to make their legacy ODF documents work and to exclude other vendors would be to specifically look in the document for the name of the application that created the document, and allow their ODF Add-in but reject OpenOffice, etc. IANAL, but I think you would agree that something like that would look very, very bad to competition authorities. So the only way out, if your goal is to hide from interoperability, is to sacrifice your Office customers who are using the Microosft/CleverAge ODF Add-in. It serves them right for not sticking to the party line in the first place. This'll teach 'em good.

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 leads me to further uncharitable thoughts. So I must stop here.

As I mentioned before, this is a step backwards. But it is just one step on the journey. Let's look forward. This is just code. Code can be fixed. We know exactly what is needed to have good interoperability of spreadsheet formulas. In fact most of the code already exists for this. The only thing we need now is to actually go do it and not get too far ahead, or lag too far behind. This is more a question of timing and coordination than hard technical problems.

  


Does MS Office SP2 With ODF Support Really Work? Test Results Point to No. - Updated 3Xs | 243 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
Corrections thread
Authored by: Aladdin Sane on Monday, May 04 2009 @ 12:27 AM EDT
Please reply to this comment with your corrections to the article.

Thanks

---
"Then you admit confirming not denying you ever said that?"
"NO! ... I mean Yes! WHAT?"
"I'll put `maybe.'"
--Bloom County

[ Reply to This | # ]

[NP] News Picks Discussion
Authored by: Aladdin Sane on Monday, May 04 2009 @ 12:29 AM EDT
Comment on Groklaw News Picks here.

Don't forget to mention which News Pick you are commenting on.

---
"Then you admit confirming not denying you ever said that?"
"NO! ... I mean Yes! WHAT?"
"I'll put `maybe.'"
--Bloom County

[ Reply to This | # ]

[OT] Off Topic threads
Authored by: Aladdin Sane on Monday, May 04 2009 @ 12:31 AM EDT
Start [OT] threads under this comment. Thanks.

---
"Then you admit confirming not denying you ever said that?"
"NO! ... I mean Yes! WHAT?"
"I'll put `maybe.'"
--Bloom County

[ Reply to This | # ]

Windows SPK2 With ODF Support Really Works...
Authored by: jkrise on Monday, May 04 2009 @ 01:13 AM EDT
It's simple. The purpose of this feature in SP2 is so that PHBs can click a
check-box while justofying their decision to throw more money at Microsoft. To
that extent, it works.

[ Reply to This | # ]

Kspread works fine for me
Authored by: IMANAL_TOO on Monday, May 04 2009 @ 01:50 AM EDT
With Kspread (2.0 beta-7) I manage to open all of the documents!

Woth OpenOffice 3.0.1 (build 9379) I fail only on Office 2007 sp2.

However, the weeks differ between the two packages. I get 14.71 weeks in OpenOffice and 14.87 weeks in Kspread.

There might be a reason for that too. How to calculate weeks differs between various countries, in particular what is week number one!

For example, see http://www.probabilityof.com/exc el.shtml

An excerpt:

The Excel function WEEKNUM(serial_number,return_type) do not return week numbers according to international standards (ISO 8601). Microsoft says very ignorant that ISO 8601 '...is a European standard that defines the first week as the one with the majority of days (four or more...'. This is an international standard! Microsoft, Please feel free to check out these standards # USA Standard: ANSI X3.30-1985(R1991) and # USA Standard: NIST FIPS 4-1 which have implemented ISO 8601. A long list of Implementation of the ISO 8601 Standard Around The World. What the #¤% is so European about this?


There is a lot to it.

.




---
______
IMANAL


.

[ Reply to This | # ]

Does Windows SPK2 With ODF Support Really Work? Test Results Point to No.
Authored by: Anonymous on Monday, May 04 2009 @ 01:53 AM EDT
Did I understand right?

Does the new plugin correctly parse formulas? And then, instead of keeping the formulas, it computes the results and throws away the formulas? Seriously?

Anyone incompetent enough to do that without noticing is incapable of writing code to compute the results of the formula (or to do just about anything). If it is to be ascribed to incompetence, then someone must have taken some ready-made code for computing the formulas, and somehow thought that the code was just for parsing formulas. I must confess that I am somewhat prone to some slight skepticism as to the degree of plausibility of the allegation that mere incompetence is the simplest comprehensive explanation.

\Cyp

[ Reply to This | # ]

Does Office With ODF Support Really Work? No
Authored by: rsmith on Monday, May 04 2009 @ 02:18 AM EDT

So the only program that doesn't work with anybody else's documents is MS office. I'm not surprised.

It is the only way to maintain their monopoly position market share.

You have to remember that there are only two ventures in the whole microsoft empire that aren't bleeding money: MS Windows and MS Office. So they have every interest of keeping people locked in.

---
Intellectual Property is an oxymoron.

[ Reply to This | # ]

Does Windows SPK2 With ODF Support Really Work? Test Results Point to No.
Authored by: tknarr on Monday, May 04 2009 @ 02:20 AM EDT

I work on a general rule about Microsoft's goals:

  1. Be able to include a checklist item saying they support the relevant standard.
  2. Raise the maximum barrier to interoperability with non-Microsoft software that their users will tolerate without causing those users to abandon Microsoft's software.
Note that actually implementing the standard correctly doesn't appear in that list of goals. In fact, doing that would be contrary to goal #2. Whether this is Microsoft's actual attitude or not, it does allow accurate prediction of Microsoft's actions.

[ Reply to This | # ]

Microsoft just gave up the developing world
Authored by: kawabago on Monday, May 04 2009 @ 03:24 AM EDT
Many countries in the developing world are settling on ODF for their document
retention and interchange. This means that no one will be able to use Microsoft
products in those countries. This time this trick is going to backfire and it's
going to burn Microsoft badly. If you have stock, sell it now.

[ Reply to This | # ]

This is so obvious, folks!
Authored by: Anonymous on Monday, May 04 2009 @ 03:32 AM EDT

As Rob Weir put it:

To get this wrong requires more effort than getting it right.

Of course! Even Homer Simpson could have predicted this. Somewhere in the depths of Microsoft, a team of clever people struggled with the following problem:

"How can we put features into Excel that let us claim Excel complies with the ODF standard, without actually writing files that non-Microsoft spreadsheets can read?"

They found a solution. They implemented it in SP2. Is anybody surprised? I mean, any conscious being who hasn't been living in a deep cave for the last 15 years?

[ Reply to This | # ]

Does Windows SP2 With ODF Support Really Work? Test Results Point to No.
Authored by: gdshaw on Monday, May 04 2009 @ 04:46 AM EDT
If you're looking for a non-malicious explanation then I think a far more likely
one is that the development team were told to ship by a particular date or else,
and they did just that.

Even so, it is difficult to see how this could have slipped though anything
resembling a testing department without those higher up being fully aware that
the ODF support was worse than useless.

I suspect that they're fishing to see what they can get away with. They can fix
it any time they want to if it starts to have a serious impact on sales, but in
the meantime it delays adoption by sending the message that ODF is more trouble
than it's worth.

[ Reply to This | # ]

Does Office SP2 With ODF Support Really Work? Test Results Point to No.
Authored by: N_au on Monday, May 04 2009 @ 07:23 AM EDT
From the looks of the results, OO.o 3.1 is more compatible with MS Office files
than MS is ODF. I was asked by a friend to print a few wedding invitations that
were missed by the person who printed them but had gone away. He said she had
emailed him the program so I didn't know what to expect. When I opened his email
what I saw was 3 files with the dreaded .docx. As I use Kubuntu 8.04 it only has
OO.o 2.4 which opened them but did not display a picture that was in the file.
However I still have XP (never used tho) with OO.o 3.0.1 so tried it and it all
worked. The only difference tho was the picture edges stood out more on OO.o as
MS office printout was more faded like a watermark, but it might have been just
different printers as she used inkjet and I used colour laser.

[ Reply to This | # ]

The ominous formating warning. . .
Authored by: Anonymous on Monday, May 04 2009 @ 08:01 AM EDT
I get that warning every time I try to save a document that isn't in docx. So
MS
is just claiming that it isn't really compatible with anything else, including
other
MS formats. I find this to be plain stupid. The basic formats for documents
haven't really changed in the last, what, thousand years? Why should we have
incompatible page formats? Purely monopoly marketing.

[ Reply to This | # ]

Evidence for the EU?
Authored by: Anonymous on Monday, May 04 2009 @ 08:11 AM EDT
The EU are currently looking at OOXML and whether there are antitrust
implications.

The table that shows that MS are incapable of interoperating with any other
package should be evidence for the EU investigations.

[ Reply to This | # ]

"Microsoft customers who used OOXML"
Authored by: pointman on Monday, May 04 2009 @ 08:29 AM EDT
(Found in the included article from Rob Weir.)

Call me suspicious, but do these customers indeed use OOXML? Is that at all
possible?

I'd assume they use Microsoft's internal variant of what was shoved down the ISO
process, but I don't think that's the same ... or am I behind, and is
"OOXML" a catch-all for anything from Redmond?

---
$29.00 and an alligator purse

[ Reply to This | # ]

Mighty Fine Lawyering (Developing)
Authored by: Anonymous on Monday, May 04 2009 @ 09:19 AM EDT
They looked at the standard and found out how to impliment it so that it was to
their maximum advantage. You expected something else?

[ Reply to This | # ]

Suggested additional test - Does MS Office SP2 With ODF ... Test Results Point to No.
Authored by: Anonymous on Monday, May 04 2009 @ 09:49 AM EDT
I realize that this a question if MS Office can export to ODF.

I would like to add an additional challenge.

Take your MS Office document. Save as an older .doc file (As opposed to .docx)

Open it with MS Office. Does MS Office open the .doc file properly.

Open the .doc file with Open Office.

I've heard something to the effect that Open Office has been updated to handle
.docx files, but I may be mistaken.

Does the .doc file or if it works the .docx file open properly?

Create the document in Open Office.org. Save is as .odf and as .doc.

Open both with Open Office.org. Do they open properly?

Open both with Windows 7. Do they open properly?

The purpose of this is to confirm or deny that it is possible, or not possible
to properly convert files using either Open Office or Windows 7. If the .doc
file is exported and imported properly in Windows 7, and in Open Office, then it
demonstrates that Microsoft is not really trying.

[ Reply to This | # ]

Does MS Office SP2 With ODF Support Really Work? Test Results Point to No.
Authored by: Anonymous on Monday, May 04 2009 @ 10:18 AM EDT
IMO, this is an example of how MS will release something before it's ready for
mainstream consumption, simply to be qualified for corporate and government
procurement checklists, which more and more are requiring ODF compatibility. So,
they can say that they support ODF, it's just that it doesn't work yet...
Typical of MS - release before read and fix in a future release (if they have
to).

[ Reply to This | # ]

Does MS Office SP2 With ODF Support Really Work? Test Results Point to No.
Authored by: MauriceS on Monday, May 04 2009 @ 10:23 AM EDT
We should perhaps bear in mind that MS Office 2007 SP2 claims only that it
supports ODF 1.1, not draft 1.2. I don't know how well that support works in
practice - I've only tested it so far against OpenOffice 3.0.1 in text
documents, but it might be worth trying MS-created spreadsheets with OOo 2.x, if
anyone still has it.

[ Reply to This | # ]

Embrace and Extend is already happening....
Authored by: Eeyore on Monday, May 04 2009 @ 11:44 AM EDT
Well, you called it. Microsoft is already starting...

If you look at Rob's updated article, it turns out that MS "ODF" DOES
have the formula in the cell (as I had already verified by looking at the XML)
BUT it puts it in the "msoxl" namespace (it's supposed to be in the
Open Formula ("of") namespace). Anyone care to bet that Microsoft
"decides" that it is "OK" to do this and leave it up to
everyone else to change their versions of ODF so they can read and update M$
spreadsheets?

[ Reply to This | # ]

Main point could have been stronger
Authored by: Anonymous on Monday, May 04 2009 @ 12:44 PM EDT
PJ, you mention in the article that you don't want people to use MS to produce
ODF documents for you. This leads me to the obvious conclusion: They have
deliberately created a compatibility issue to diminish the credibility of ODF.
Now when you get an ODF file, you may or may not be able to use it. Hence you
will no longer trust the ODF format. Genius on MS's part!

[ Reply to This | # ]

Take action!
Authored by: Anonymous on Monday, May 04 2009 @ 02:28 PM EDT
The developers should have had interoperability with other ODF readers in mind. They didn't, or not these particular readers. QA should have done their homework, particularly a large company like MS. They didn't.


At this point, we can react in one of two ways. We can wring our hands and cry "how horrible". While this may be entertaining, it's a game of NIGYYSOB. If our only goal is vindication, then sure, that works.


Or we can try to get the problems corrected.

The easiest way to do that would be to create sample files that don't work correctly, and send them in. Provide "What didn't work", "What created the file", and "What read the file" (versions as well as apps/plugins). Sending the file to both the creator and the reader is a good idea; both may want to adjust things.

And think of it this way. Either a) they will take the files and the problem reports, and correct them. Yay, more interoperability.

Or b) they will toss them out, at which point you can switch to the "malice" theory. "They were informed of the problem and did nothing about it."

Do send it to the appropriate developers. "Mentioned it on a blog somewhere" doesn't count as "informing the developer of a flaw in the program." Really. Even if the blog is high profile like this one.


[ Reply to This | # ]

A great quote
Authored by: rcweir on Monday, May 04 2009 @ 03:08 PM EDT
From Microsoft's 2008 press release announcing that SP2 would support ODF:

Microsoft recognizes that customers care most about real-world interoperability in the marketplace, so the company is committed to continuing to engage the IT community to achieve that goal when it comes to document format standards. It will work with the Interoperability Executive Customer Council and other customers to identify the areas where document format interoperability matters most, and then collaborate with other vendors to achieve interoperability between their implementations of the formats that customers are using today.

I wonder, what every happened to trying to achieve "real-world interoperability in the marketplace" "between formats that customers are using today"?

[ Reply to This | # ]

deja vu - just like the msooxml fiasco all over again
Authored by: Gringo on Monday, May 04 2009 @ 09:45 PM EDT

Just came back home to Groklaw after reading discussion on this on Slashdot for the past couple of hours. The discussion there has MS shills swarming all over it like flies on a piece of ^H^H^H^H excrement. They keep hitting the same "talking points" over and over. Some patient, informed slashdotter replies to each, then the shills just repeat their argument. It goes on like that for 5 pages at the point I left. MS has their army out in full force tonight. It's just like when the polemic on msooxml reached its peak. MS learned a lot from that battle. Just stick to the party line, no matter what anybody says, and in the end, they get away with it. I call it "The Wall" - or - "...I've got my fingers in my ear and I can't hear you."

Now on Groklaw we have just been honoured by a visit from a high level shill who engaged Rob Weir in a little joust (which I think is still in progress as I write) - only he didn't reply to Rob Weir but rather resorted to a variation on the ad homen attack, painting Rob Weir as rabidly anti-Microsoft and only seeking advantage for his employer.

Sorry Mr. Shill - I have been following Rob Weir for a couple of years now and find him to be a level-header person, and I admire his courage in standing up to your employer. You and your colleagues will never convince me and thousands like me with your empty rhetoric. Your day is over. The jig is up. You have been thoroughly exposed. Microsoft domination is very bad for this world, and an exponentially growing number of people are realizing that. It doesn't matter how many politicians you have in your pocket - your days are numbered. We don't want you around any more.

[ Reply to This | # ]

Tuning out the white noise -- Red Hat vs. Microsoft results
Authored by: Anonymous on Monday, May 04 2009 @ 11:15 PM EDT

Well, let's see. Microsoft is up to its usual tricks. Nothing new there.

So, pardon me if I look past all this and focus on the earnings trends of Red
Hat and Microsoft. Which one is getting better, and which one is getting worse?
What else do you need to know?

I see IBM and Apple also have been doing fairly well, but they sell hardware,
and Microsoft doesn't, so I guess they don't count. But Dell sells hardware,
too, and they're having problems lately. Maybe if they branched out with their
OEM software offerings . . .

All you Microsoft shills showing up lately, please explain these trends.

[ Reply to This | # ]

Does shilling really work?
Authored by: Anonymous on Monday, May 04 2009 @ 11:25 PM EDT

Is there any objective evidence that Microsoft's paid shills are actually
helping the company?

The shilling is such obvious astroturf, no one could possibly give them any
credibility. Why, then, does Microsoft do this?
Why say something if you know that no one will believe you?
I've never understood this.

If Microsoft really thinks it works, it goes a long way toward explaining their
present financial head cold.

[ Reply to This | # ]

Another piece of the puzzle
Authored by: rcweir on Monday, May 04 2009 @ 11:46 PM EDT
An important post to re-read from last August, from Microsoft's Doug Mahugh, entitled "Guiding Principles for Office's ODF Implementation"

I find little to disagree with that post. The intentions stated there are quite reasonable:

  • "When we found the specification to be ambiguous, we decided to follow common practice as long as it adheres to the standard."
  • "We also don’t want to be accused of 'co-opting' ODF and 'polluting' the cyberspace with many ODF files that don’t adhere to the standard."
  • "Be Predictable. The principle here is that we want to do what an informed user would likely expect."
  • "Preserve the user’s intent"

This is all goodness at least stated as an intent. So what happened between November and now to cause the results we now observe in SP2? Surely, there is a "common practice" in ODF spreadsheet formulas that could be followed while still adhering to the standard. And certainly stripping spreadsheet formulas is not what the user would likely expect nor does it preserve their intent.

[ Reply to This | # ]

Conformance without interoperability...
Authored by: Anonymous on Tuesday, May 05 2009 @ 08:50 AM EDT
But here's what I learned: you can be conformant to a standard and *not* interoperable at the same time.

That's what will likely happen every time you produce a complex, abstract standard that isn't developed in parallel with a fully working reference implementation and a substantial validation suite. Trying to follow a standard without those is... well, I imagine trying to construct a legal argument without reference to precedent or caselaw would be similar.

Unless you manage to persuade the omniscient superhuman entity of your choice to draft the standard it will contain ambiguities and contradictions - and what combination of misconceptions leads anyone think that a committee can spot those? Give it to a programmer to implement, then test the result with realistic applications and then you might have a standard.

Most successful bit of interoperability? How about the "RFCs" that lay down the fundamental protocols for the internet? Highly informal, written by engineers for engineers.

[ Reply to This | # ]

If Microsoft were so sincere ...
Authored by: radical1 on Tuesday, May 05 2009 @ 03:04 PM EDT
They should have had people review the functionality using external sources such
as Rob Weir.

When I worked for a large corporation as a manufacturing engineer we continually
need tool designed to support production. We had a tool design department. But
they were useless. To get a tool, you had to fill out a request form and submit
it. Then approximately 4 weeks later, they called you into their office (I
thought to review requirements for tool desired) and they then submitted a tool
to me. It would not work. Where was the communication?

After a number of engineers complained (same scenario) the department was
abolished and new tool designers appointed. Any tool coming from the new crew
was good, as they always called upon the engineer to discuss exactly what was
required.

OK, enough with old stories. So my question is, if Microsoft were so sincere,
why did they not publicly test it? I guess the answer if of course, they
weren't sincere.

[ Reply to This | # ]

Backlash?
Authored by: bigbert on Tuesday, May 05 2009 @ 05:29 PM EDT
Well, we could turn this around, you know:

"Look, Mr. PHB, all these packages work EXCEPT the new Microsoft stuff. And
remember how slow your new PC was with Vista? Clearly MS has dropped the ball
again. I suggest you complain to the MS rep next time you see him."

I certainly intend to do this. And before the MS rep can start talking about
standards, I'll just say: "But why can all the others manage but not
you?"

They started it, now I'll feed them a dose of their own misinformation.

---
--------------------------
Surfo, ergo sum.

[ Reply to This | # ]

Does MS Office SP2 With ODF Support Really Work? Test Results Point to No. - Updated
Authored by: Anonymous on Tuesday, May 05 2009 @ 11:27 PM EDT
get over it, ODF, OOXML or whatever "standard" you want to try to
push, is just that... a pipe dream.

standards are generally defacto, generic or determined by the usage.

Batamax Vs VHS, Beta while technically better, lost to VHs, Beta is technically
better (why it was still used in TV and studio's). but the people chose to make
VHA the standard.

Now in computers, sorry guys, the standard (defacto, real or otherwise) is
Microsoft, its .doc, .docx, .xls and so on.

You can try to introduce other standards, but if the people dont use it, or they
dont care, (and they dont), whats the point.

Anyway, if OO.o and all these FOSS packages are so much better than what windows
does, why do you want to copy and emulate them ??

Why it is not OO.o SETTING THE STANDARDS, in functionaly, usability and
POPULARITY.. (dont worry, i know why).

I just hope one day you people will work it out before its too late..

[ Reply to This | # ]

Does MS Office SP2 With ODF Support Really Work? Test Results Point to No. - Updated 3Xs
Authored by: Anonymous on Thursday, May 07 2009 @ 03:01 AM EDT
Weir's article boils down to these two lines:

"Also, the fact that the Microsoft/CleverAge add-in correctly reads and
writes the legacy ODF formula syntax shows not only that it can be done, but
that Microsoft already has the code to do it. The inexplicable thing is why that
code never made it into Excel 2007 SP2."

The code has a BSD-like license so it can legally be incorporated into Office
and since Microsoft is providing the money for the project you can expect that
it won't be too difficult to integrate.

The conversion code hasn't made it in to Office 2007 yet. That's all that's
going on here. I suspect the coders for Office 2007 SP2 were working against the
draft spec and not targeting an implementation (like OpenOffice), both of which
are moving targets. And I also suspect the coders have little experience with
this kind of conversion code which is why this has apparently been outsourced to
DIaLOGIKa. Due to MS' glacial development pace it probably won't be integrated
until Office 2010.

Weir is right, the majority of existing .ods documents probably use the legacy
OO code so from a user experience perspective a case certainly can be made to
support this in ODF import. But he has spun this into a political issue to argue
that the proprietary OpenOffice legacy code should be a requirement in the ISO
standard until OpenFormula is ready (which is based on the OpenOffice legacy
code and just happens to be the native format of his company's product),
essentially forcing Microsoft to support the OO legacy formulas in order to gain
ODF 1.2 compliance.

[ Reply to This | # ]

Does MS Office SP2 With ODF Support Really Work? Test Results Point to No. - Updated 3Xs
Authored by: Anonymous on Saturday, May 09 2009 @ 12:57 AM EDT

The form of these conflicts is really ages old, from way before there were even
computers.

It used to be called "eminent domain" back in the day - and which side
one was on nearly completely guided the tenor of one's response in the struggle
du jour.


Without pushing the analogy too far, it is probably safe to say that ODF
developed as a result of real needs which were not being met, and which existed
largely because the *structure* of Microsoft's dominance effectively precluded
such needs from being satisfied by them.

It is also safe to conclude that Gray's responses are unsurprisingly oblivious
to this context, since from his point of view there is no discernible reason for
any struggle. Since Microsoft is dominant, its ineluctability is a foregone
conclusion to such adherents - hence any serious conflict ends up representing a
direct attack on the joint efforts of the world he inhabits, regardless of any
other possible interpretations.


Sadly, many "open" advocates get pulled into this false representation
as well, and much "bashing" and "we can never trust you"
moments abound as a result.


Please, people, try to be clear about this - it is not a war, it is
fundamentally different paradigms in confrontation. Microsoft cannot help
operating from the "hindbrain", it's just the kind of beast it is.



All you nice li'l mammals can take your warm blood & communal sharing into a
future where you can eventually leave all this behind - we all learned something
about trails of tears, so we don't need to repeat that any more ...

[ Reply to This | # ]

Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details )