eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Sun Microsystems ODF Plug-in for Microsoft Office wont usher in an era of universal document interoperability, but eWEEK Labs believes it is the best option currently available for adding Open Document Format support to Offices massive installed base. The plug-in, which Sun debuted on July 4 in the form of a freely downloadable 30MB installation package, enables users to read, edit and save ODF-formatted word processor, spreadsheet, and presentation documents using the 2000, XP, and 2003 versions of Microsoft Office.
Unlike the Microsoft-sponsored Open XML/ODF Translator project, the Excel and PowerPoint components of which are still in development, Suns freely-downloadable ODF Plug-in is a bona fide shipping product—complete with optional paid support from Sun. Also in contrast to the Microsoft-sponsored translator, which was developed from scratch and uses XSLT, a language for transforming XML documents into other XML documents, Suns plug-in is backed by proven document conversion code from OpenOffice.org. However, file conversion with Suns ODF plug-in works differently than in OpenOffice.org, as the plug-ins import and export filters work with Offices built-in text converter to get the job done, yielding slightly different results than when I used OpenOffice.orgs converter alone.
Overall, I found file conversion in Word, Excel and PowerPoint to be on par with the document conversion in OpenOffice.org, but, as with OpenOffice.org, conversion isnt perfect. I did run into slight, yet noticeable, formatting issues. For instance, one of the ODF presentation documents I opened, modified and saved as a PowerPoint file lost some of its shaded regions in the translation. When I saved the same modified presentation in ODF format, the shading stayed, but the document came through with some misaligned text.
While Sun has done a good job integrating its plug-in with Word, adding ODF to Words standard file type dialog and letting users set ODF as Words default format, the plug-in isnt as well integrated with PowerPoint and Excel. With these applications, users trigger the plug-in instead through “import to ODF” or “export to ODF” in the applications file menus and tool bars. Also, I found the plug-ins knack for triggering multiple “Are you sure you want to do this?” dialogs each time I saved or opened a document somewhat grating.
I encountered some bugs in Suns packaging of the application. Specifically, in my tests with Office 2003, the installation process did not make the needed DLLs available to the application. According to Sun officials, this bug will be fixed in the next release of the converter, v.1.1, scheduled within the next few months. On the plus side, the plug-in doesnt have additional requirements, such as the Microsoft Office Compatibility Pack or .Net Framework, both of which the Microsoft-sponsored plug-in demands.
Version 1.0 warts aside, Suns plug-in can play an important role in broadening interoperability. As OpenOffice.org and other ODF-based office applications become adopted more broadly (by the state of Massachusetts, for starters), Microsoft Office users will want the flexibility to communicate with partners or customers using these applications. A bit of advice, though: When collaborating on complex documents, its best to stick to the same application and format.
Anyone whos working with partners or customers running OpenOffice.org or another ODF-based office application will find this plug-in a worthwhile download. Its free, (with Sun offering additional support at extra cost) and the plug-ins installation is easy, so it makes sense to visit www.sun.com/software/star/openoffice and begin getting familiar with the software.
Next Page: Conversion quality.
Conversion Quality
To test the Sun converter, I used an ODF-formatted word processor, spreadsheet and presentation document, opened each file in Office 2003 using the Sun ODF plug-in, made a small modification to each file, and then saved the modified documents in both ODF and Microsoft Office formats. I then printed out the original document; the modified, ODF-formatted document; and the modified, Office-formatted document for comparison. Ideally, all three would end up looking the same, save for the small modifications Id made. As it turned out, conversion anomalies surfaced in both my test documents, but those anomalies were different in the ODF- and Office-formatted documents.
I began with a sample OpenOffice.org word processor document packed with formatting, which I opened with the Word 2003/Sun plug-in duo, modified slightly, and then saved in .doc and .odt formats. Errors that cropped up in both the modified .odt file and converted .doc file included incorrectly sized bullets and incorrect footer formatting. Also, the original .odt document demarked its footer with a line across the page, a design detail that appeared in neither the modified .odt file nor the converted .doc file.
My modified .odt file failed to reproduce the documents entire page range inside the footer. Instead, the page range appeared as: “Page 3 of.” In the converted .doc file, tabs from the .odt file failed to translate on the page, page breaks also fell at different locations, and, in one instance, the row numbers in one of the files tables didnt materialize.
Next, I took a sample OpenOffice.org presentation filled with charts and graphics, imported the presentation into PowerPoint 2003 using Suns plug-in, made a few modifications, and then saved the presentation in .ppt and .odp formats. As with the word processor documents I tested, both my modified presentations contained some formatting errors.
The most glaring errors in the .ppt file revolved around the presentations design elements: Significant shading details failed to translate into the .ppt file, resulting in much more white space in the .ppt file than in the original presentation. In some places, text also drifted off the pages of the .ppt file. Alignment issues also marred the .ppt file, with text boxes and graphics spaced lower on the page than in the original file.
The modified .odp file fared better. Very slight alignment issues surfaced in the modified .odp file but were barely detectable. Youd almost need a magnifying glass to ascertain the differences in how the two lined up. However, a hyperlink on the presentations opening page did not translate into the modified .odp file.
Of the office application triumvirate that Suns ODF plug-in targets, the application that gave the plug-in the most trouble was Excel—at least where saving in .xls format was concerned. Once again, I began with a sample OpenOffice.org spreadsheet that featured a detailed bar graph, which I opened with the Excel 2003/Sun plug-in duo, modified slightly, and then saved in .xls and .ods formats.
The .xls file, intended to chart the hours logged on a time sheet, was rife with formatting issues. The number of entries in the hours-logged column (which runs vertically down the left side of the graph) totaled 16 on the original ODF spreadsheet, yet the .xls file only listed 9 entries—an obviously problematic difference. Given this deletion of entries in the hours-logged column, the remaining bar graph was also significantly reduced in its overall size, with fewer cells, which meant a reduced column length. The .xls document also occupied a smaller area of the page, and its shaded areas appeared much lighter than those from the original ODF-formatted spreadsheet.
The modified .ods file, on the other hand, maintained very good conversion fidelity.
Check out eWEEK.coms for the latest open-source news, reviews and analysis.