Conversion Quality

By Tiffany Maleshefski  |  Posted 2007-07-27 Print this article Print

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 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 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 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.


Submit a Comment

Loading Comments...
Manage your Newsletters: Login   Register My Newsletters

Rocket Fuel