Sun building support for SpreadsheetML into OpenOffice


I missed this last week: http://blogs.sun.com/GullFOSS/entry/office_open_xml_import_filter

It looks like some folks in Sun are working on support for Ecma 376’s SpreadsheetML format within Open Office:

The development of a new spreadsheet import filter has been started in the Calc project. This filter will be able to read the Office Open XML file format for spreadsheets introduced in Microsoft Office 2007. The filter is already able to load simple cell contents (strings and numbers). Currently I am working on cell styles and cell formatting…

This is very cool. There are some other spreadsheet tools out there already that have varying levels of Open XML support, and it’s cool to see that Sun is working on adding this into OpenOffice. Some of the folks from Novell who were on Ecma TC45 work directly on the OpenOffice source, but I’m not sure how much they are directly involved with this latest project.

-Brian

Comments (6)

  1. hAl says:

    Isn’t this going to be the same sort of thing as the  word processing converter by Sun and the DaVinci converter that not actually convert the OOXML but convert the binary memory data via MS Office?

  2. Adam says:

    So? Folks at Sun were presumably involved in adding support for Excel 2003, XP, 2000, ’97, ’95, 5, 4, 3, etc… formats, along with Lotus 1-2-3, Quattro Pro, etc… as well.

    This doesn’t necessarily mean they like the format or endorse it in any way, merely that they’re painfully aware that no matter how good a format this may be, on whatever merits it happens to possess (or not), because MS are going to make this the default format for Office 2007, and because MS have a stranglehold on office software through their secret legacy file formats, there are going to be a lot of documents in this format around also. Hence, if they don’t support it (and all it’s related stupidity, *cough*1900-not-a-leap-year*cough*) there’s not much point in them making a spreadsheet program.

    Let’s hope they have 150 man-years(!) to throw at the problem.

  3. W^L+ says:

    hAl, converting directly from memory without an intermediate (incompatible) file format is the most effective and efficient way to do this.  The MCAN plug-in *should* have done this instead of using XSLT on an output format that isn’t fully able to be transformed to/from that way.

    I realize that by making it so inconvenient to use the ODF file formats, they expect to deter people from making ODF the default file formats for their organizations.

    (MCAN = Microsoft, Clever Age, and Novell; since Novell is/was planning to use this plug-in as the basis for adding OOXML support in OpenOffice.org.)

  4. hAl says:

    @W^L+

    Even if it is efficient to convert from MS Office memory it is of limited use to a plugin for OpenOffice as OpenOffice is likely to be on a computer that does not have MS Office installed on it.

  5. Doug Mahugh says:

    I’m having a super-busy week, so I’ll let others do the talking for a change … I just learned from

  6. Stephen says:

    @W^L+ … why don’t you join the translator project and give them the benefit of your design insights?