Submitted by A Microsoft-sponsored open-source project is expected on Friday to release a translator that will convert file formats between Microsoft Office and rival standard OpenDocument, or ODF. Microsoft started the project at SourceForge last year, relying on three partners to develop the code that lets a user open and save word processor documents in two different formats.
but will I be able to use this translator in MacOSX, Linux, in OpenOffice?
Sure doesn’t look like it from the title of the project: “OpenXML Translator (ODF Add-in for Word)”
You don’t need to, OpenOffice works with ODF files natively.
Read the article, it is a “translator”, to turn DOC files into ODF files, therefore enabling programs that utiles ODF, ie, OpenOffice, to access files that previously were proprietary, ie DOC.
sheeeeesh !!
I find that calling it “translator” is misleading, because it is a Word plugin. If you do not have access to a copy of MS Word, you cannot turn .doc’s into ODF’s with this plugin.
//I find that calling it “translator” is misleading, because it is a Word plugin. If you do not have access to a copy of MS Word, you cannot turn .doc’s into ODF’s with this plugin.//
That is true of any “plugin for MS Office” … it isn’t going to work without MS Office.
If you have a Windows platform, and you do not have a copy of MS Office, and you want to view ODF format documents, you can use this:
http://opendocumentfellowship.org/odfviewer
If you have a Windows platform, and you do not have a copy of MS Office, and you want to work with ODF format documents, you can use any of these:
http://opendocumentfellowship.org/applications
Office suites
Application Native Status Platform
OpenOffice.org Yes 4 stars Linux, Windows, Mac
StarOffice Yes 4 stars Linux, Windows
Workplace Yes 3 stars Linux, Windows
Of those choices, OpenOffice is free to use, but it is a very large download. 94 MB for the file OOo_2.1.0_Win32Intel_install_en-US.exe .
OpenOffice.org has a batch translator feature. It will allow you to select a whole batch of MS Office documents and convert them all to ODF.
In the near future, the daVinci plugin, a version of MS Office and a “batch convert macro” may be able to do a better job of this task that the current OpenOffice does.
Edited 2007-02-04 06:28
but will I be able to use this translator in MacOSX, Linux, in OpenOffice?
Apparently so. It only works with Word files for now though, not Excel or PowerPoint. I’m more interested to see if it actually works well or if it has lots of formatting problems.
Novell last year said it will use the Word translator to allow users of OpenOffice, which supports ODF, to work with OOXML files from Microsoft Office.
It only works with Word files for now though, not Excel or PowerPoint.
The reason for that is that the only part of the ODF standard that is fleshed out enough to actually implement a working program is the wordprocessor part. The spreadsheet part is incomplete by a long shot. There’s good reason for the OpenXML specification being so large.
The word processor part is the best defined, but that hasn’t stopped multiple oss apps from implementing spreadsheet and presentation software using the ODF format. This project is supposed to start on excel next i think, so obviously they don’t think it is impossible either.
//The reason for that is that the only part of the ODF standard that is fleshed out enough to actually implement a working program is the wordprocessor part. The spreadsheet part is incomplete by a long shot. //
Fixed in ODF version 1.2.
http://en.wikipedia.org/wiki/Opendocument
“OpenDocument 1.2 is currently being written by the ODF TC. It will include additional accessibility features, metadata enhancements, spreadsheet formula specification based on the OpenFormula work (ODF 1.0 did not specify spreadsheet formulas in detail, leaving many aspects implementation-defined) as well as any errata submitted by the public. Originally OpenDocument 1.2 was expected by October 2007.[6] However, upon learning that many of its activities will be completed far before then (e.g., the formula subcommittee expects to complete in December 2006), the group has agreed to develop a newer accelerated schedule.[7]”
BTW, the formula subcommittee did indeed finish its work by December 2006.
Your “long shot” has already been fired and it missed its target.
Edited 2007-02-04 02:18
//The reason for that is that the only part of the ODF standard that is fleshed out enough to actually implement a working program is the wordprocessor part. //
Err, that is not actually true. There are several programs already that use ODF 1.0 that implement a full spreadsheet program.
http://opendocumentfellowship.org/applications
Office suites
Application Native Status Platform
KOffice Yes 4 stars Linux, Unix
OpenOffice.org Yes 4 stars Linux, Windows, Mac
StarOffice Yes 4 stars Linux, Windows
Workplace Yes 3 stars Linux, Windows
Mobile Office Yes 1 star1 star1 star Symbian
Spreadsheets (other than suites)
Application Native Status Platform
Gnumeric No 2 stars Linux
Google Spreadsheets No 3 stars All (web-based)
EditGrid No 2 stars Any (web-based)
The “problem” is that ODF version 1.0 leaves some details about formulas undefined, and so interoperability between applications is a problem. There is no problem in actually having a spreadsheet, just in moving the spreadsheet files between applications using ODF 1.0 format.
This lack of portability of spreadsheet files is fixed, however, in the soon-to-be-approved ODF version 1.2.
Edited 2007-02-04 04:45
Well, it is an OSS project, so noone is gonna stop you from getting an cvs dump and start hacking.
//Well, it is an OSS project, so noone is gonna stop you from getting an cvs dump and start hacking.//
There is no point.
The whole project is doomed from the very outset. It will never achieve 100% fidelity conversion form OOXML to ODF, because of the very nature of OOXML.
All effort should instead be directed at conversion directly between the internal memory representation of a document in Office and ODF. This is what the daVinci plugin does, and it has enromous advantages over the CleverAge approach. The primary advantages are that there is no need for OOXML, and ODF can be set as the default format with no loss of functionality of Office.
Why waste effort on a doomed approach that requires OOXML anyway?
Full MS Office support can help the format to take off. For example it can be adopted as a standard format even where MSOffice is currently used.
Then Openoffice will follow as a good alternative.
the reason why it was MS who developped the plugin
is because they knew somebody would do it,
so it had to be them who control the development.
It’s obvious that Microsoft has lost this battle and had to give in and support ODF if they didn’t want to be out of the game sooner than later.
With many governments and organizations supporting open formats (which means ODF in most cases), Microsoft had no other choice than support the format or nobody would buy their new office suite that couldn’t handle many official documents.
Now that they won’t be able to force users to use MS Office to inter-operate with others, let’s see how many actually buy Office 2007 based just on its merits (which I don’t question, by the way).
Irrelevant.
Most users think they “need” MSoffice because the rest of the world uses it.
If the rest of the world switches to ODF, these same users will think they still need MSoffice to access these files too.
Besides, OpenOffice has no Outlook, so how can Joe User get his email ?
OpenOffice also doesn’t have a web browser.
But neither does MS Office.
OMG, How will Joe User check slashdot?
I’m assuming this was done just to act as a talking point while trying to talk companies out of openoffice. They know full well that if it’s not included in word, almost no user is going to download and install a plugin like this.
And if they did include it people would probably still find a reason to bitch and moan.
//And if they did include it people would probably still find a reason to bitch and moan.//
Au contraire, if Microsoft abandonned their pretense about how ODF is allegedly inferior or alleagedly unable to support their leagcy formats, and instead included native full support for ODF (such as that provided by the daVinci plugin), then I for one would whloeheartedly applaud Microsoft.
Providing the equivalent of the daVinci plugin (which is a trivial effort for Microsoft … which is reportedly what Microsoft’s own engineers told Massachusetts) for versions of Office back to Office ’97, would finally show just one instance of Microsoft doing something for their customers.
Not only should Microsoft provide such, it should be provided as an integral capability of Office 2007, and as a plugin for all previous versions of Office.
If Microsoft did this, I would consider purchases of Office 2007 and Vista. As long as they do not provide such full support for open standards, backwards compatibility and freedom from lock-in, Microsoft will never see any of my money.
Even if you applauded them, others would still find a reason to bitch about it.
“They’re just trying to buy good PR” or what have you.
Or: “This is their standard embrace, extend and extinguish. You’ll see!” -tactic.
I’m afraid it will only be used when mandated by the organization people are working for.
If MS Office can save and load Lotus file natively why not ODF ?
Why need to let the user take extra steps to have the ODF function where it does not infringe any patent , copyright issue or against anti-trust law like PDF case.
If the plugin in allow user to change the default save format , I think ODF user will appreciate. However, I doubt MS will allow that.
I think when user want to export the file to ODF , the classic message “You will lost some formatting …bla bla” will appear , and the default is not encouraging user to save to another format.
By the way, is the plugin usable in MS Ofice 2000 ?
//If MS Office can save and load Lotus file natively why not ODF ?
Why need to let the user take extra steps to have the ODF function where it does not infringe any patent , copyright issue or against anti-trust law like PDF case.
If the plugin in allow user to change the default save format , I think ODF user will appreciate. However, I doubt MS will allow that.
I think when user want to export the file to ODF , the classic message “You will lost some formatting …bla bla” will appear , and the default is not encouraging user to save to another format.
By the way, is the plugin usable in MS Ofice 2000 ?//
You raise some excellent questions here.
The answer is, the CleverAge translator, sponsored by Microsoft, is not a full plugin. It is a translator.
To explain: a translator does its best to “translate” a document between OOXML format (where some information is already obscured) into ODF.
The points to note are:
(1) the OOXML has to exist in the first place, so a Microsoft Office 2007 version of the file must necessarily exist before this plugin can get you a rough ODF equivalent.
(2) the translator cannot be used as a native file format, and you cannot set it as the default file format,
(3) the translator does an imperfect job, only roughly about as good as OpenOffice does, and
(4) although Microsoft did not write this translator, they sponsored it and they set its technical direction, so it is Microsoft who directed that it be a translator, and hence incapable of being set as the default file format.
Now, there is another option, soon to be released, called the “daVinci” plugin (curiously, this one was not sponsored by Microsoft).
http://www.fr0mat.org/
http://opendocument.foundation.googlepages.com/home
The daVinci plugin provides an option to use ODF as the default file format.
http://fussnotes.typepad.com/fr0mat/2006/07/plugin_default_.html
This is, of course, the way it should be done.
The daVinci plugin can work in all versions between Office 97 and Office 2007. It can save old legacy-format MS Office files in ODF format with 100% fidelity. You can set ODF as the default save format. You can use it to interoperate between MS Office and any other Office suite on any other platform. You can use it to “de-obfuscate” all of your old, archived MS Office documents, so that these documents can be read far into the future.
You can even use it to provide inter-operability between different versions of MS Office, so that if the boss buys a new Vista computer then it won’t mean that all of the machines in the company must also be upgraded in order that all the staff can read the boss’ documents.
There is hope for Windows users to finally escape the lock-in.
Just don’t use the Clever-age translator, use the daVinci plugin instead (when it comes out), and set your default format (on all of your machines) to ODF.
Edited 2007-02-04 02:02
I cannot understand why people criticise the project, without even reading it’s techinical specs or developer blogs.
(4) although Microsoft did not write this translator, they sponsored it and they set its technical direction, so it is Microsoft who directed that it be a translator, and hence incapable of being set as the default file format.
They did not build a file format plugin, but prepared a converter for technical and practical reasons.
On their blog, they clearly describe why they’ve chosen the current development model (C# + XSLT):
http://odf-converter.sourceforge.net/blog/index.php?2006/09/04/4-c-…
* The core is in XSLT, so other projects (like OpenOffice) can incorporate it natively.
* They’ve chosen C# over C in order to code in a shorter time and use OOXML as core (for a plugin they’d have to use RTF instead).
* Additionally if you do not like the current state of the project, you can use its sources for another alternative (license is BSD after all)
It can save old legacy-format MS Office files in ODF format with 100% fidelity.
No it cannot. If you check the page at http://odf-converter.sourceforge.net/features.html , you’ll see that there are “disjoint” features not shared by OpenDocumentFormat and OpenXml. So it’s technically impossible to write a 100% converter.
Edited 2007-02-04 11:42
//No it cannot. If you check the page at http://odf-converter.sourceforge.net/features.html , you’ll see that there are “disjoint” features not shared by OpenDocumentFormat and OpenXml. So it’s technically impossible to write a 100% converter. //
Well, all the more reason not to use OOXML then isn’t it? It is especially stupid to use OOXML as an intermediate stage in a process that is trying to produce ODF as the final output, isn’t it? Why are you even attempting to do what is technically impossible?
Why not just use the same process as Microsoft use to produce OOXML (which is: internal memory data <-> OOXML) to make ODF instead (like this- plugin: internal memory data <-> ODF) as the daVinci plugin does it, rather than the “technically impossible” (CleverAge convertor: internal memory data <-> OOXML <-> ODF) that the CleverAge converter uses.
As you point out, what the CleverAge plugin is trying to do is technically impossible to do 100%. It is not however impossible to do a 100% conversion like Microsoft does it for OOXML … and like daVinci does it for ODF.
However, please note your observation is not what I actually said.
What I actually said was “It can save old legacy-format MS Office files in ODF format with 100% fidelity.”
This in fact the daVinci plugin can do. What is more, the capability has been demonstrated.
In this context, 100% fidelity means that a legacy-format MS Office is saved as ODF by the plugin. The ODF saved file is then read back in by the plugin, and saved back as a legacy-format file. The files survives the “round-trip” 100% intact.
OOXML cannot do that. The CleverAge plugin cannot do that.
The daVinci plugin can do that.
As far as the fidelity of the file when it is in the ODF format – some data is saved as “metadata”. Other ODF applications will have some difficulty reading the metadata … but that is because Microsoft has obscured the old legacy formats and utterly refuses to reveal their full structure.
Nevertheless, the conversions done by the daVinci plugin are better than those done by OpenOffice.org, and considerably better than those done by the CleverAge convertor, which is the topic of this thread.
Edited 2007-02-04 12:36
//Additionally if you do not like the current state of the project, you can use its sources for another alternative (license is BSD after all) //
You can use it sources to try to make a better convertor which (after Office 2007 has already done a conversion (internal memory <-> OOXML) then attempts to do a conversion OOXML <-> ODF (which as you say is technically impossible).
However the sources are utterly useless if you are trying to write a save-as-ODF capability as the default file format. The CleverAge sources are utterly useless as (internal memory <-> ODF) which is what the daVinci plugin does.
//They did not build a file format plugin, but prepared a converter for technical and practical reasons. //
You mis-spelled “political”.
The daVinci plugin demonstrates that a “file format plugin” is both technically and practically a 100% viable thing to do.
Any software architect worth his salt would have written an ODF capability without going via OOXML first. It is blatantly obvious you should do it direct to ODF, not via OOXML. The only reason why you would go via OOXML first is if you had a political agenda to make OOXML necessary …
Edited 2007-02-04 12:48
You can use it sources to try to make a better convertor which (after Office 2007 has already done a conversion (internal memory <-> OOXML) then attempts to do a conversion OOXML <-> ODF (which as you say is technically impossible).
Apparently there are some things that are used by OpenOffice that cannot be represented by MS Word, and vice versa. It’s not only about file formats or converters.
However the sources are utterly useless if you are trying to write a save-as-ODF capability as the default file format. The CleverAge sources are utterly useless as (internal memory <-> ODF) which is what the daVinci plugin does.
They were very clear (from the beginning) that they’re building a converter in short time. And they now distribute an open source two way OOXML – ODF converter.
The converter (as of now) can be used as an add-in or from the command line for batch conversion work (which is much more useful for large corporate needs). Additionally you can build a generic web service (for you document management system, etc).
And calling the sources “utterly useless” is not very nice. The current code is not in a format directly usable for save/open plugins, right. But it can be adapted to do that.
Actually it’s easier to use the sources in OpenOffice (which will be done by Novell soon).
You may not like the project, or it’s goals. But let’s not call it (utterly useless), or claim their motives are “political”.
//Apparently there are some things that are used by OpenOffice that cannot be represented by MS Word, and vice versa. It’s not only about file formats or converters. //
This is what Microsoft would have you believe, but it is not actually so, and the daVinci plugin demonstrates that very well. The representation of some things is different, but they are simply different representations, and it most decidedly is not “impossible” to convert from one representation to the other.
It is, however, impossible if you insist that OOXML is an intermediate stage of the conversion. That is because OOXML deliberately obscures some of the information in a way that is very, very difficult to deconstruct back to ODF. One is tempted to think of OOXML as a XML schema designed to represent the same information types as ODF but be as difficult as possible to translate to ODF.
//The converter (as of now) can be used as an add-in or from the command line for batch conversion work (which is much more useful for large corporate needs). Additionally you can build a generic web service (for you document management system, etc). //
This things can all be done with existing OSS software, and the existing OSS software does a far, far better job.
What cannot be done with the CleverAge approach is: (a) achieve perfect conversions, or (b) set ODF as the default file format.
//And calling the sources “utterly useless” is not very nice. The current code is not in a format directly usable for save/open plugins, right. But it can be adapted to do that. //
No, AFAIK, it cannot. It requires OOXML as input data for file save, and it converts ODF to OOXML on file load … neither of which processes actually save or load the document in memory. To get a document in to and out of memory using the CleverAge approach still requires that the first action in file save/open is the default OOXML action … only OOXML interacts with the document in memory, not the CleverAge software. By design.
The daVinci plugin, however, by design, does interact directly between the document in memory and ODF. It does this in the same way as the default file save/open interacts with OOXML. The daVinci plugin therefore completely replaces OOXML.
Doing it that way, the daVinci plugin achieves the following capabilities that are forever beyond the way that the CleverAge software works:
(1) daVinci can be used to set ODF as the default file format,
(2) daVinci can be written for all versions of Office back to ’97, and hence achieve interoperability between all the different versions of Office,
(3) daVinci can achieve 100% perfect round-trip fidelity in save-as-ODF/re-load-ODF operations.
(4) daVinci can “expose” in the ODF format everything that is known about the legacy format information in Office documents, and it does a far more comprehensive job of this that any other conversion utility.
Compared to daVinci, the CleverAge software, requiring as it does OOXML as an intermediate step, is indeed utterly useless.
The CleverAge software will never have a hope of achieving the features numbered (1) to (4) above. It is crippled … by its very design.
Microsoft themselves wrote OOXML as a direct memory <-> file format load/save process, so they knew that can be done, and they knew it could also be done for ODF. Since Microsoft set the design of the CleverAge software deliberately so it was not an equivalent process (memory <-> file format) to OOXML, it could never do features (1) to (4) above, and so, yes, doing such a thing is entirely political.
//You may not like the project, or it’s goals. But let’s not call it (utterly useless), or claim their motives are “political”.//
Pray tell, why on earth not?
If it walks like a duck, and it quacks like a duck, you may as well call it a duck.
Edited 2007-02-04 22:37
“Novell last year said it will use the Word translator to allow users of OpenOffice, which supports ODF, to work with OOXML files from Microsoft Office.”
Hmmm, Novel intend to use this translator as the basis of their OOXML compatibility.
That means that the Novel “interoperability” with OOXML will necessarily be limited, because of the obscured bits of OOXML.
Backup reference: http://openstack.blogspot.com/2007/01/opendocument-as-perfect-micro…
“The OpenDocument format (“ODF”) is able to handle anything Microsoft Office can throw at it, and handle it at least as well as Microsoft’s new EOOXML file formats. That includes the bound business processes, assistive technology add-ons, line of business dependencies and advanced feature sets unique to various versions of Microsoft Office. The converse however can not be said of Ecma Office Open XML — the new Microsoft EOOXML file formats — as evidenced by Microsoft’s own ODF Translator Plug-in Project difficulties.”
Interesting.
That means that NOT going with Novell, but using daVinci + MS Office + ODF as your interoperability solution, will give you a far better result than the “official” Microsoft/Novell deal will.
I am a bit of a newbie in these matters so pardon me if this question is silly. I know there are some features in Excel (like Pivot Tables) that is missing or limited in oo.o or koffice. I am guessing this is probably not due to limitations in ODF per se. So what would happen on conversion? Might still be lock-in if the recipient can’t modify the file – though strictly speaking it is not MS’s fault.
Edit: I realize this is not directly related to this Word plugin but just looking ahead (optimistically) to a day when the excel equivalent is released.
Edited 2007-02-04 05:45
//I know there are some features in Excel (like Pivot Tables) that is missing or limited in oo.o or koffice.//
In OpenOffice Calc, to do the equivalent of a pivot table, you select Data->Data Pilot from the menus. There is not quite the power provided in the OpenOffice application as you get with Excel pivot tables.
http://www.openofficetips.com/blog/archives/2004/09/datapilot_101.h…
http://www.openoffice.org/product/calc.html
“Advanced DataPilot technology makes it easy to pull in raw data from corporate databases; cross-tabulate, summarise, and convert it into meaningful information.”
There is no problem in viewing pivot tables from Excel spreadsheets, and no problem for the ODF format to store a pivot table. The small limitations of OpenOffice are in the OpenOffice application itself, not in the ODF format per se.
Edited 2007-02-04 06:11
Well, you can’t do it perfectly yet.
There are at least two solutions that do this imperfectly:
OOXML -> (load) -> OpenOffice memory -> (save as) ODF.
OOXML -> (load) -> Office 2007 memory -> export to ODF using CleverAge converter.
AFAIK the first of those achieves the best result, but I could be mistaken about that. Neither conversion is perfect.
There is promise soon of a better process however:
OOXML -> (load) -> Office 2007 memory -> (save as) ODF using daVinci plugin.
That one should yield a near-perfect conversion. It will also allow you to continue to use all of your existing business processes built around Office and other Microsoft products such as Sharepoint.
So, if you have saved any of your documents in OOXML, then all is not lost and you are not necessarily locked in to Microsoft platforms quite yet. There is still a chance for you to have cross-platform interoperability and ISO standards compliance. All that is required is to shift over to ODF as your document standard format when the daVinci plugin becomes available.