Slashdot Mirror
ODF Plugins and a Microsoft Promise of Cooperation
Andy Updegrove writes "Last week, the Massachusetts Information Technology Division (ITD) issued a Request for Information (RFI) on any plugins that might be under development to assist it in migrating from a MS Office environment to one based upon software that supports ODF. The RFI acknowledges the fact that it may be necessary or advantageous to see some of the code in Office in order to enable the types of features that the ITD is looking for. Conveniently, Jason Matusow, Microsoft's Director of Standards Affairs, had this to say on the occasion of ODF's approval by the members of ISO and the IEC: "The ODF format is limited to the features and performance of OpenOffice and StarOffice and would not satisfy most of our Microsoft Office customers today. Yet we will support interoperability with ODF documents as they start to appear and will not oppose its standardization or use by any organization. The richness of competitive choices in the market is good for our customers and for the industry as a whole." Presumably such support will include helping the plug-in developers that will assist Massachusetts migrate from a MS Office environment to one based upon ODF-compliant office productivity software."
As groklaw has already reported there is a plugin for importing and exporting ODF files for MS Office all the way back to Office 97. It was recently finished and is in testing.
Seriously, open up a Word document that you've worked on and modified several times. Select the whole document, copy it, paste it into a new document, and save it. The documents should largely be identical (you might've missed headers and footers or page margins). Now compare the fize sizes. The old document might be several megabytes. The new one is probably a few hundred K.
What's missing? Gobs and gobs of metadata about every keystroke, ever action, every cursor positioning.
Ever open up a Word document, scroll arounda nd read but make no changes, close it, and have Word ask to save changes? Metadata.
The road to tyranny has always been paved with claims of necessity.
On May 4th, slashdot covered the followup to this story. Now, three days later, they get around to mentioning the original story. I guess this doesn't actually qualify as a dupe, but it's definitely some sort of mutant nephew of a dupe, or something.
No. About ten years ago I read an interview by a top executive from Microsoft (Nathan Myrwold, iirc) that most features do not come from customer requests, but from magazine comparisons. When someone wrote an article comparing different office suites they would include a table with tickmarks showing which features were included in each software. It became an obvious competitive advantage to have more tickmarks than the competition.
In that interview, Myrwold mentioned that MS-Word had over a thousand different commands, and that was a problem because most of those commands would never be used by the majority of users and it had a big impact on usability. That's how Clippy was born, it was an attempt to concilate the wants of marketing who insist on putting useless features with the needs of users who want to perform simple tasks most of the time.
Beyond that, I can't say there's too much I've run into that I can do in Office but not OO.o . A lot of things are much smoother in Office, though
I think MS's argument is a lot weaker with regards to the file format, though I'm certainly no expert. I do expect that they'll be able to implement their own formats with better performance in Office than the ODF formats, but that's hardly surprising given that they designed them with that as one of their key goals.
More interestingly, the Office XML formats require implementing programs to preserve unrecognised valid markup from other namespaces. This lets you do things like embed (eg) an order record in an Office document, embed a JDF specification (when Publisher gets around to going XML as well), and so on. It's not exciting for the end user, but for developers and larger businesses it's a really nice thing to see. One could argue that Microsoft are getting XML "right" in a way that few have so far. Most interestingly by far, you can link the foreign markup in to your Office documents, so that (eg) a user can fill in a form in a document that's actually an XForm with your own structured data. Alternately, a newspaper could insert some custom metadata when exporting stories from a database, so it can tell what's been done with it, keep the DB up to date when the story is imported again, and so on. It's quite interesting stuff. Check out Brian Jones' weblog for some interesting use cases and discussion (and some persistent questions about the licensing issues from me).
The ODF spec only briefly refers to this issue at all. IIRC it permits apps to do this perservation, but does not require it or provide any facilities to support it. If apps aren't required to preserve your markup, then in my view it's not much darn good - it's somewhat like saying that apps may preserve your document text and structure. OpenOffice doesn't preserve foreign markup at all. If it's not directly in the ODF spec, you can't use it. This really loses one of the great advantages that XML has, and is very disappointing.
If we had a standard office document format that I could rely on having these features, there are some very interesting things I could do with it, especially at work. This fragementation and the ODF limitations are extremely frustrating, especially given that the ODF folks are always banging on the XML gong while missing one of the key abilities of XML entirely.
I think MS screwed up very badly at the start by attacking ODF with rhetoric and poorly thought out garbage, not a solid arguement over capabilities and other real issues. Insufficient audiovisual support indeed...
Personally I don't care much whether ODF or MS Office XML wins, so long as the resulting standard:
The issue with ODF as it's come up (and Massachussetts in particular) is that they wanted to be able to publish information for the public in a format that they could use regardless of several factors, the big two of which are choice of representation and futureproofing. As has been related many many times before, there are aspects of Microsoft's own Office formats that do not get imported - or get imported in a broken state - when opening documents in more current versions of Office than they were saved in. This is where future-proofing come in.
The idea is that the constituents of the Commonwealth should be able to read the digital documents produced by their government. It is FUD in the most classic sense that the idea was to mandate some ODF-only office suite that allowed people to work only in ODF. This is not the case. The point is accessibility for the final product.
Think of a magazine. Magazines are commonly laid out in Quark XPress (as a common example). Quark has features like revision control, graphics control, text kerning and leading and flow-control. Myriad tweakable parameters that allow the people who work on the magazine to make it look and read the way they feel is best. We as magazine readers do not need this functionality at all in order to read the magazine. We just want to be able to pick up the publication and flip through the pages and read stories, look at pictures, and so on. These are two completely different modes of interacting with the document that are not mutually exclusive, but that intersect in the act of publication. ODF is this simplified translation for uses that do not require things like XAML.
This is where Microsoft sought to sow seeds of doubt that the sky of document creation and workflow was falling. This is not the case, and what we read here is that what ODF proponents predicted has come true: Microsoft would not stand in the way of their users choosing to "Save As..." in the ODF format. It's just bad business for them to do so and I for one see this story as Microsoft acknowledging a big, fat "I told you so."
I don't even want to touch the accessibility/ADA aspects of embedded media, which is entirely uneccessary for the purposes that Massachussetts wants to use ODF for, but that Microsoft purported to be 110% necessary for anybody to create documents in the future. They were trying to embrace and extend their reach into the very act of creating a document. Is any government document dependent on the creator being able to publish their Inkitudes in a native format? I don't think so! The fact remains, however, that government employees can use whatever techniques they like to create a document, but if it's going to wind up being a public document then people need to be able to access it forevermore. I certainly didn't see them promising THAT in the runup to MA's decision to use ODF.
ODF is just another output format and there's no reason that the laws and other byproducts of governmental communication can't be published in a format that people can be confident can be incorporated into future products - it being an open and documented format - and won't be aged out in favor of Microsoft's decision that maybe Ink should be the lingua franca of Office formats (downsampled into Palatino if desired). Microsoft did not want to cede control of one iota of their Office franchise and they preferred to be able to hold the reins on just what software would be able to read a Microsoft Office document.
When I was a kid, we only had one Darth.
It depends on how they do it. If they impliment a working standards compliant version... well, that'll be great.
Based on what they did to Java, HTML and everything else they have ever touched it'll be a almost compliant version, to an out of date standard, that is a massive pain in the ass to use with non-MS products. (Ref IIS/IE/Frontpage etc etc.)
Beep beep.
"Ink" information can be stored in an ODF document using the Gif format as a metatdata container. This can be specified by using the Gif parameter of the Ink.Save Method.
From MSDN;
Gif
2
"I've got more toys than Teruhisa Kitahara."
Another alternative is R, which is much more powerful than anything MS Office has to offer, is Free, and runs on most platforms.
That's the disadvantage of being a habitual criminal, trust is hard to come by.
The ODF format is limited to the features and performance of OpenOffice and StarOffice
Micro$soft is lying through their nose. They know very well that KOffice, the Free & Open Source office suite that comes with the KDE desktop environment also supports the ODF format. In fact, they were publically informed about KOffice's capabilities last year in a open letter sent by the KOffice developers.
Yet they continue to spread the outright lie that only OpenOffice and its derivatives support the Oasis Open Document Format (ODF).
KOffice has a much cleaner architecture and a leaner codebase than OpenOffice, making its startup faster and facilitating the addition of new features. Because improving KOffice to meet the usability needs of governments, businesses and disabled individuals can be done with much less effort, KOffice is an even greater threat to Micro$oft.
Get computers and accessories from Linux-friendly manufacturers