"Microsoft Word users now can easily import and export to the OpenDocument Format. The StarOffice 8 Conversion Technology Preview, a plug-in for Microsoft Word 2003 that allows users of Microsoft Word 2003 to read, edit and save to the OpenDocument Format is now available."

I just tested this out, and in many ways it's better than the Microsoft-sponsored ODF add-in.

To use the MS-sponsored tool with Office 2003, you have to install .NET 2.0 PLUS OpenXML filters PLUS the add-in itself. The MS tool is EXTREMELY slow at opening ODF files (40 seconds to a minute), and it is not integrated into the open/save dialogue boxes, which is pretty annoying.

Meanwhile, this Sun tool is easy to install, about as fast as any other conversion, and integrates right into the open/save dialogues. Unfortunately, it refused to convert one ODF I tried to open that had a table in it, whereas the MS tool did just fine. Also, for some reason with the Sun tool a security check ("this could be a malicious file") pops up every time I open an ODF. Hopefully these problems will be ironed out in the final release.

The only (very) annoying thing is that you have to register on Sun's website to download it, and you have to download it using Sun's download manager, but perhaps this will change once the final version comes out.

The only (very) annoying thing is that you have to register on Sun's website to download it,

That probably won't change. Licensing, etc. Not a big deal.

and you have to download it using Sun's download manager, but perhaps this will change once the final version comes out.

That isn't true. I thought the same thing the first time I only saw a download button for SDM. Just click the link to the item on the download page to get a direct download link. Click the download button to use the download manager.

Yeah... Now all we need is for Microsoft to follow suit by releasing OpenXML filters for OpenOffice. Heck, as long as they're open source, I'm sure the KDE and GNOME guys wouldn't mind porting them to KOffice and "GNOME Office" (as if the latter really exists anymore).

It boggles my mind that this format can be an ECMA (and ISO now?) standard without an open reference implementation. We all know that MS is one of those corporations that simply doesn't care about what anyone else thinks, so it's not like we can do or say anything to expedite this process.

There's a saying that if the entire population of China jumped from a 1-meter height at the same time, it would create a tidal wave that would swamp the entire US. However, this is actually 8 orders of magnitude short of the energy released in the San Francisco earthquake of 1906. If the entire population of China jumped at the same time in protest of Microsoft's document formats, they wouldn't feel a thing in Redmond.

It boggles my mind that this format can be an ECMA (and ISO now?) standard without an open reference implementation.

The problem isn't that there isn't an open reference implementation, the problem is that the proposed standard contains references to old extinct Microsoft products. E.g. it says things like "handle line breaks like MS Office version x". If you no longer can get hold of that version of office how are you supposed to make an implementation of your own, or test that your implementation actually follows the standard.

BTW, as far as I know OpenXML hasn't been approved as ISO standard yet and many principal standards bodies have filed contradictions.

I suppose that's an important subset of the fact that there is no open reference implementation. These references to back-level MS Office functionality make it significantly harder to implement the specification, but by no means impossible. But would there really be any objection to this minor hurdle if Microsoft supplied an open reference implementation? I can't image it being very hard for a borderline-retarded person with an Internet connection to acquire a copy of every gold release of MS Office. Then it might take a week for a competent document suite developer to play around with the features referenced in the spec and characterize how each feature operates in the indicated version.

Compared with other structured data format specifications, OpenXML is certainly towards the top in sheer size and scope, but it's not terribly obscure, particularly because it is a text-based XML format designed to be compatible with one of the most popular software products of all-time. However, this is not just an specification, this is to be an internationally recognized standard for describing rich documents. It is simply too massive in size, scope, and world-wide socioeconomic implications to be adopted as a standard without an open reference implementation.

The problem isn't that there isn't an open reference implementation, the problem is that the proposed standard contains references to old extinct Microsoft products. E.g. it says things like "handle line breaks like MS Office version x". If you no longer can get hold of that version of office how are you supposed to make an implementation of your own, or test that your implementation actually follows the standard.

Those are optional attributes whose implementation is not required to conform to the standard.

Just tried it out...looks great to me. If Sun can competitively price support for this product it will be a great transition tool for companies with existing support contracts with Microsoft/IBM/EDS etc.

1) SDM is an optional thing; Sun has always pushed the idea of it being the 'optimal' way of downloading their software; you can download using a browser, but to save support issues, they've provided a download manager as neither Firefox or Internet Explorer supports resume, pause or start.

2) All very nice, but only Word is supported; to make it worth anything, the ODF plugin needs to support all their applications.

3) Hasn't addressed the issue relating to VB macro's - what there needs to be is a cross platform language; be it a Java based language which provides cross platform and not overly complicated; at the risk of snickering from the cheap seats but how about COBOL like language? that would make life easy, the language is simple enough for the average user.

4) OOXML is complicated because of the way Microsoft defined the specification - defined every part of the thing, right down to the very last comma, full stop and frame - which will cause problems for others to implement; if Microsoft wants genuine interoperability as they claim, then they need to step up to the plate and make a BSD licenced filter available with full documentation.

Before one starts a Microsoft-bash-a-thon, they aren't the only ones who say one thing and do the complete opposit; Sun does the same thing, screams the virtues of choice in hardware and willingness to support non-Sun hardware, and yet, 2-3 years or so after x86 support resumed, the hardware support for non-Sun hardware is just as bad as it was before; its worse than FreeBSD; when a group of volunteers can produce better hardware support than a team of professionals, there is a dire need for a inquiry into what programmers at Sun are really doing during their time when they're supposidly working.

2) All very nice, but only Word is supported; to make it worth anything, the ODF plugin needs to support all their applications.

"worth anything"? I've heard of sarcasm, but really, that's just silly. It is very much worth *something* at the very least. In fact, I'd venture to say a lot given that Word is what the *overwhelming majority* of companies, etc. use today.

3) Hasn't addressed the issue relating to VB macro's - what there needs to be is a cross platform language; be it a Java based language which provides cross platform and not overly complicated; at the risk of snickering from the cheap seats but how about COBOL like language? that would make life easy, the language is simple enough for the average user.

I don't see this as being with the scope of this plugin. Not only that, I don't see Microsoft adopting a cross-platform scripting language anytime soon (though they could do it with Python since they've already started with it...).

I don't see this as being with the scope of this plugin. Not only that, I don't see Microsoft adopting a cross-platform scripting language anytime soon (though they could do it with Python since they've already started with it...)

Yes it is in need of support; you *NEED* support for VB Macro's as they are vital for many organisations; they automate work flows via making repeative jobs easier.

Will Microsoft support it? no, but does the world need Microsoft support to make it? of course not! create a language, plug it in to replace/compliment Microsoft Office and voila, problem solved.

I haven't had a look into Office 2007, but as far as I remember it supports VB.NET - if you get VB.NET working in OpenOffice.org, the portability of files would be massive; those held hostage to Office due to their reliance on VB macros would become a thing of the past, and would allow them to gradually deploy OpenOffice.org rather than the current situation of having to do it all at once.

[I haven't had a look into Office 2007, but as far as I remember it supports VB.NET - if you get VB.NET working in OpenOffice.org, the portability of files would be massive; those held hostage to Office due to their reliance on VB macros would become a thing of the past, and would allow them to gradually deploy OpenOffice.org rather than the current situation of having to do it all at once.]

PS: Effort to produce this compiler was not part of the MS/Novell deal. De Icaza also added that these improvements in Mono owe nothing to Microsoft and Novell's recent technical partnership. "The deal with Microsoft didn't help with this project. "

That doesn't actually address the issue which I said; VB.NET macro support in OpenOffice.org - the article just talks about VB.NET in regards to 'stand alone' applications.

Considering that Microsoft themselves isn't even going to support VB Macros on all the platforms they support Office on, I find it hilarious at best.

Not only that, you do realise the wonderful patent portfolio that surrounds VB and how Microsoft has been threatening lately to use that patent portfolio to put those down who don't use their IP right?

I don't see a patent minefield like that ever being officially integrated into OpenOffice.org.

http://tirania.org/blog/archive/2006/Dec-04.html"Today we ship modified versions of OpenOffice to integrate GStreamer, 64-bit fixes, integrate with the GNOME and KDE file choosers, add SVG importing support, add OpenDMA support, add VBA support, integrate Mono, integrate fontconfig, fix bugs, improve performance and a myriad of others. The above url contains some of the patches that are pending, but like every other open source project, we have published all of those patches as part of the src.rpm files that we shipped, and those patches have eventually ended up in every distribution under the sun."

[2) All very nice, but only Word is supported; to make it worth anything, the ODF plugin needs to support all their applications.]

Yep. From the article, this is due in April.

[3) Hasn't addressed the issue relating to VB macro's]

AFAIK this isn't an issue for a plugin for Microsoft Word - VBA macros will still run just fine. I believe they are saved to file as "metadata" in ODF format.

As it says ... seamless operation.

[4) OOXML is complicated because of the way Microsoft defined the specification]

Why worry about OOXML at all? Just use ODF as your default format (even for MS Office), all interoperability problems solved. Use the plugin as an OOXML substitute. Don't save anything at all as OOXML. Ideal solution. Solves interoperability and escapes lock-in all in the one go.

Your other choice, of course, is the daVinci plugin from the OpenDocument foundation. This one is also not quite ready yet.

3) Hasn't addressed the issue relating to VB macro's - what there needs to be is a cross platform language; be it a Java based language which provides cross platform and not overly complicated; at the risk of snickering from the cheap seats but how about COBOL like language? that would make life easy, the language is simple enough for the average user.

I think this is beyond the scope of the converter, but speaking of scripting in MS office, at some point MS is looking to make the .net framework the scripting platform in office.

I haven't checked to see if this is indeed the case in 2007, but if and when it takes off we may find that a future release of mono could offer cross-platform macros.

"Three Conversion Approaches to Consider::
What we have then are three conversion methods, all enabled through an easy to install plugin model, and each with a different level of conversion fidelity:

* The MS Translator XSLT method (EOOXML <> ODF) :: note that this initially was an application and platform-independent approach. In the strict sense, this is a "transformation", not a "conversion"

* The Sun external OpenOffice.org conversion engine method (MS Binary Files <> ODF) :: note that the OOo conversion engine is based on years of reverse engineering needed to understand the secret structure of those mysterious and enigmatic billions of binary documents. A secret only Microsoft can unlock with perfect fidelity.

* The Foundation's daVinci "internal" conversion process (MS in-memory-binary representation <> ODF) :: note that this process harnesses the internal conversion methods of Microsoft Office applications in much the same way as the EOOXML Compatibility Pack."

I think the Sun plugin announced by the topic article is more like the daVinci plugin method (MS in-memory-binary representation <> ODF) than it is like the OpenOffice.org method (which is based on the legacy binary file formats).

How is Office 2003 obsolete?? 2007 came out barely a few weeks ago and I know not a single person running it, and I don't know of a single company in our area planning to upgrade to it for quite some time.

If I were writing something, you could be damned sure I'd be writing for the largest deployment, not necessarily the newest release.