ODF vs OOX : Asking the wrong questions

Recent posts from Brian Jones (Microsoft) and Robert Weir (IBM) highlight the strange times we live in. A squadron of flying pigs are out doing loops. On one hand you have MS documenting their file format, and providing positive press for competitors. On the other you’ve got IBM paying full time staff to critique development versions of Gnumeric. I’d like to thank both authors for their publicity, and triaging, but I also want to point out that IMO their examples are looking at things the wrong way.

Brian’s example of Numbers reading an OOX file written by Gnumeric could just as easily been an XLS file. Indeed that would likely have had better support on both ends.   The binary format was poorly documented and a miserable pain to read, but it’s been around a long time as is the dominant interchange format. All spreadsheets needed to support it.

Rob heads off in another direction with his examination of Gnumeric’s limited support for xlsx, on both import and export. What he neglects to consider is the amount of effort required. The initial importer was written on the flight to London for the ECMA meeting, and export was added on the flight back. Toss in a few hours of debugging and the sample file produced by Brian’s example was under a week of effort to read and write. After reading his post I added basic chart import and export the following day.Basic XLSX chart import

This was several orders of magnitude simpler than writing the binary filters which required parsers for OLE2, BIFF, and binary expressions just to get far enough to start reading the format details. However, even that is not the most salient question to ask. The core of this argument is the OOX vs ODF showdown. Instead what implementers really want to know is :

How hard was it to implement ODF support compared to OOX ?

it was significantly more difficult. To be clear, ODF support was nowhere near as much work as the old binary filters, we are talking about XML here. However, while Import filters start with parsing the structure, in the end, extracting the basic state is no more than the ante for the real work. You need to handle the impedance mismatches between the concepts in the file format, and your implementation. ODF’s model of ‘chartness’ didn’t fit well with Gnumeric. In contrast XLSX may be ugly, but it”s concepts were very familiar from XLS. We already had much of the code required to handle it.

I suspect most spreadsheet implementers are in the same position.

33 Responses to “ODF vs OOX : Asking the wrong questions”

  1. Bjoern Milcke Says:

    If you have two XML file formats and one implementation, and you note that implementing one of the XML formats more easily there can only be made one conclusion: your implementation is closer to that file format.

    This says nothing about the quality of the file format as such.

  2. Jose Says:

    So, what you are saying is: because of your previous experience in reverse engineering the old microsoft file formats, the ooxml spreadsheet file format file importer implementation was easier and faster than the “new” odf spreadsheet file format. You just had adapt the already existing code.

    Wow. That’s FANTASTIC! What a great endorsing for ooxml! You must try provide this comments to Microsoft so they can used them in the BRM meeting for ISO approval.

    Taking into account the difficulties that Microsoft itself is having to implement its own formats on Mac OS, you must volunteer to help them.

    And must haste in telling everyone how difficult it is to implement ODF in comparison to OOXML. They shouldn’t waste so much time for nothing. After all the new Microsoft file formats are already used by 95%-99% of the world’s population.

  3. Stephane Rodriguez Says:

    What Brian claimed is “very rich support”. He was lying, and he didn’t try it either. What Rob meant was that usually you want to show the most complex case you support, not something simple.

    Note the use of “support” above. Support is different than “conforming”. Gnumeric does not conform to the documentation, except in the case you assume everything in it is optional (which is kind of the ridiculous game those Microsoft employees have been playing for just about as long this thing exists). So when you say it took a couple of days to do what you did, I absolutely agree, since it’s the time it took me to add something comparable to my product as well. But that’s not the point. The point is not how little time it takes to support a couple angle brackets. The point is how far you can go, and if you answer this, you still haven’t answered the conformance issue.

    It’s disingenuous at best to say it took a couple of days to write an import and export, and render/calculate in the middle, since Gnumeric is a ten year old project. Think about someone starting now, from scratch. It’s not easy to render a cell, or even just support shared formulas, when you start from scratch.

    It costs nothing to start a project that reads and writes angle brackets. But let’s not under-estimate what it takes to implement even a fraction of this stuff.

    By the way, can you please name a product that mimics 100% of Office 97 functionalities? This product shipped ten yeatrs ago. BIFF and OLE weren’t the hard parts. The lack of completeness of the documentation certainly was, and still is, obviously. Do you have hope that you will find a serious non-Microsoft Office 2007 competitor sometimes in the future?
    It’s one thing to be an optimist, it’s another to play fool./

  4. Mitch 74 Says:

    If I understand what you are saying, is that for you, OOXML is easier to implement because, due to it being an ‘XML dump’ of previous numeric M$ file format, it is easier to implement than ODF?

    Okay, I think that’s a fine point – it is, after all, OOXML’s selling point.

    Now, would you be able to answer the following question: if, for one reason or another, you had to implement both import filters from scratch – this may happen if, maybe, Gnumeric needed a complete overhaul that made its internal structure completely incompatible with the existing filters, and those would need to be rewritten –
    , which would be easier to write? OOXML or ODF import filters?
    At the same time, and this one is much more open-ended, which format do you feel would be easier to extend?

  5. jody Says:

    Bjoern : I did not comment on the quality of the formats. That will come up later.

    Jose : I’m a neutral 3rd party trying to implement both formats. If you don’t like my conclusions I won’t force you to read them.

    Stephane : Please supply a citation where Brian claimed ‘very rich support’, that would have been baloney. Until Rob’s post there was no chart export. However, a quick search of his post only has that quote in one of your comments. The remainder of your comments confuse me. I’ll have a look at them in the morning.

  6. Florian Reuter Says:

    Hi Jody,


    Great stuff!

  7. Miguel de Icaza Says:


    For the sake of history, I want to add that Gnumeric had no file format when it was first created. It was just a spreadsheet that tried to be close in terms of UI functionality to Excel and I spent quite a lot of time on that to give it the polish that at the time I felt was important.

    I had never built a spreadsheet, back in 1998 there were no good external implementations (Oleo, KSpread and SC just did not cut it), and there was no useful data coming out from Google.

    Daniel Veillard created Gnumeric’s original file format (the .gnumeric files) and it was an XML file format that showed the actual internal details of Gnumeric, which if you compare with ODF and OOXML is very different. It reflects Gnumeric’s flavor at the time. The format evolved as we discovered limitations and problems with it, but the spirit mostly remained.

    The Excel support came later from Michael Meeks (and a friend of his, I forget whom) who had himself one of the few references materials that were available.

    The excel support was for a very long time “experimental” and you can actually tell that it was not incorporated or had a strong influence in the core of Gnumeric as we kept it back in the day as a plugin.

    Eventually the code matured and it was merged, but the main interface in gnumeric had been the public C API that Gnumeric exposed to plugins. I took pride back in the day of the clean code in Gnumeric (and am sure it is just as nice nowadays).

    So Gnumeric internals were not designed around Excel. Some of the concepts certainly were, and am sure that for some of the advanced pieces (graphics) Jody did borrow many ideas from Excel, but at least the original stuff back when I worked on it was based purely on the UI experience that I wanted to provide.


  8. Matthew Cruickshank Says:

    I think your post could easily be misconstrued as saying that OOXML is easier to implement than ODF, when really you’re only saying that OOXML builds upon Gnumeric’s existing reverse-engineering of Microsoft Office and that ODF doesn’t.

    Because Gnumeric has had to interchange with XLS so frequently the design of Gnumeric and its internal data structures and functions have evolved to act like Microsoft Office and not like others. In other words, your comparison isn’t about what’s easier to implement from a sufficiently abstract codebase, yes?

    I hope that what I’ve said isn’t too disagreeable. It’s just that your choice of words could be easily obscure the message of your post, and lately people have been willing to take quotes of context in order to prove that OOXML or ODF is better than the other.

    (to me it’s obvious that the duration of a plane flight wouldn’t allow for big changes because good software like Gnumeric takes years to write, not hours… when you describe tasks in metric-plane-trip-hours it can be very unclear to non-programmers 😉

    Anyway, again, I hope I’m not saying anything too disagreeable. It’ll be good to see what you think about the quality of the formats, as I’ve written for both of them too.

    By the way — is the goal of the import/export filter to implement plain old vanilla OOXML as prescribed, or OOXML+Office 2k7 extensions? (eg those OLE binaries that Office ’07 has… stuff like that).

  9. Pepe Says:

    Jose, I think it’s clear that the difficulty of implementing ODF or OOX into an already existing spreadsheet app is dependent on how close that app’s spreadsheet implementation is to OO.o’s Calc or MSO’s Excel, respectively.

    For example, ODF’s model of “chartness” didn’t fit well with Gnumeric because ODF’s model of “chartness” is based on Calc’s model of “chartness”. Gnumeric’s model is more closely aligned with Excel’s than Calc’s so OOXML was easier to implement into Gnumeric than ODF. Spreadsheets that are more similar to Calc than Excel will find the opposite results.

    The point being, both formats are plagued with the disease that they favor particular spreadsheet implementations over others. ODF favors Calc (and those that are simlar) and OOX favors Excel (and those that are similar).

    That’s my reading of it, anyway.

  10. Sidney Says:

    I disagree that the question that is related to the “core of this argument” is “How hard was it to implement ODF support compared to OOX?” What you implemented is a good start for OOXML support in Gnumeric, and the relative ease of that step for OOXML compared to ODF is an interesting result. But all that shows is that the previous work on xls gave you a back end that was useful when it came time to work with the related OOXML format.

    The real question is, “How hard will it be to implement fully conformant and complete support for ODF compared to OOXML?”

    Microsoft’s claim is that OOXML is necessary as a target to faithfully translate legacy MS Office documents, and that ODF can never serve that function. If they are correct, then if you are able to implement full OOXML (the spreadsheet portion) in Gnumeric, then you will be able to use Gnumeric to faithfully render any legacy MS Office spreadsheet file. If you also fully implement ODF spreadsheets, then either you will have proven Microsoft wrong (because you could use Gnumeric to read any legacy or OOXML file and write it out as ODF with no translation error), or you will find that there are spreadsheets that Gnumeric cannot properly write out as ODF.

    Now you could say that Gnumeric is not intended to be as complete as all that, and it would be fine. There is no reason why every spreadsheet program should have to be usable as a universal translator of all legacy office documents. But then it is not going to be something that Microsoft can point to as proof that full OOXML can be implemented by anyone other than themselves.

    That is Rob Weir’s point. Gnumeric’s OOXML import and export may be an interesting and useful accomplishment, but it is not the shining example of cross-platform communication that Brian Jones was touting it as. How easy it was for you to do it has nothing to do with Brian Jones’ claims about it.

  11. Stephane Rodriguez Says:

    Here is Brian’s quote : http://blogs.msdn.com/brian_jones/archive/2007/08/07/iwork-08-supports-the-open-xml-formats.aspx

    “Gnumeric – Gnumeric is an open source spreadsheet application that was one of the first applications out there to show support for SpreadsheetML. The latest build from this summer has very rich SpreadsheetML support.”

    By the way, in my comment, I forgot to mention that before I was able to support the first angle bracket of SpreadsheetML, it took me a month to create a generic OPC library. And all my unit tests work on Windows exclusively, it probably would take more to get it working properly on a non-Windows OS.

    Have you seen Microsoft pseudo-rebuttal of Google’s partner announcement with CapGemini? Read on this blog post (http://blogs.zdnet.com/microsoft/?p=706), especially points 6 and 9. Isn’t this the same old story over and over again? Why, according to you, Mr Jones is praising Gnumeric while Microsoft themselves are saying that other Office suites out there are not cost effective because they don’t support everything MS Office does? Don’t you think the praise of Gnumeric is just temporary, convenient for Microsoft at the moment because they need to show evidence that non-Microsoft people are developing stuff? Of course, be sure that those praises will automatically stop sometimes in late February when the paid-for ISO stamping will be complete.
    Disingenuous at best. Microsoft confuses a starting project from a comprehensive implementation, not to mention a competing product.
    Perhaps it’s lost on you, but Microsoft licenses the Ribbon user interface, and the license is very explicit : not licensed to competitors.

  12. Sam Hiser Says:


    Your self-annihilating devotion to Microsoft is too evident. Filtering will be unnecessary when an authentic Universal Document Format exists.

    Sadly ‘Interoperability’ — the word — is being worn out while there are no self-respecting efforts to do anything except control the data of customers.

    Shame on the business!

  13. Miguel de Icaza hablando claro. - vtortola Says:

    […] tiene un mínimo de objetividad a la hora de opinar. Curiosamente, otro desarrollador open-source escribía en su blog sobre la dificultad de implementar ODF sobre OOXML. Parece que los que aportan código suelen tener […]

  14. Otto Says:

    I’m not certain I understand the point of this post. Of course it’s simpler to implement the OOXML spreadsheet: You had already implemented it. You just called it XLS or Excel before. All you had to do was to make it output the XML document instead of the XLS one. I’m sure there were some minor differences, of course, but the gist of it was already there.

    However, it’s important to note that the actual official “standard” should not be about what is easy to implement. It should be about doing it “the right way”. If you want to argue that OOXML is “the right way” to implement document formats, then I’ll disagree with you, but I’ll have more respect for your position. (Okay, okay, I may laugh a bit, because I think that there’s no way you can legitimately argue that position while still sounding sane, but I’ll at least not say that you’re talking obvious FUD.)

    But just because it was easier to implement OOXML in one particular case (or even all currently existing cases, virtually all spreadsheets have had XLS support up until now) says nothing about the quality of the OOXML or ODF standards themselves. It just says the specific details about one specific case.

    We should not choose a standard based on what’s “easy to implement”. We should choose a standard because the standard is the correct way to do that thing.

  15. jody Says:

    Sam : Please call me wife. She’s under the impression I’ve spent the majority of my free time, for the last eight years, working on gnumeric and related free software because I was disgusted by undocumented file formats, and unpatchable code.

    Stephane : Thank you for the reference. I agree, to have called gnumeric’s OOX export abilities ‘rich’, in Aug. Was BS. My goal for the next stable release is to put OOX on the same level as XLS. At which point we’ll still be missing features, but it will be at a level that people have found useful.

    On the other hand if it took you a month to write OPC support tools you need better tools. The initial OOX patches in gnumeric included OPC support. I’ve had to extend it slightly to support hyperlinks, but it’s been stable for months and now lives in libgsf-1.14.6.

    Sidney: Baloney. Every existing spreadsheet is in a similar position to Gnumeric. We’ve all had to focus on xls import. By extension it seems logical that my experiences will generalize. I don’t expect to see permanent positive press from MS any more than I’d expect OO.o to continue to praise kspread. At the end of the day we compete in the market place. However, that is also beside the point. Gnumeric’s goal is to be useful to spreadsheet users. To that end I’ll happily support a superset of the useful features other people come up with. To claim that ODF is the one true way wastes too many useful cherries, and users.

    Gnumeric will never be able to read all of OOX or ODF without a loss. Neither will anyone else other than their native appications. At the end of the day they are different object models, and I may try to implement a supset of them in places, but there are things in each that can not be reproduced in the other. Heck even the formulas are different. I’m having to add varioius ‘odf.foo’ functions to support the ODF variant of common routines that are intentially different than XL because XL was deemed too inconsistent.

    Mathew : I have not seen any ‘office 2007’ extensions in my tests so far. The goal is to support the format at least as well as .xls.

  16. jody Says:

    otto : I 1/2 agree with you. OOX is certainly not ideal. However, if you want to argue that ODF _is_ the ‘right way to do it’ I’ll respectfully disagree. The question of which could become the one true format is about as interesting to me as vi vs emacs or star-wars vs star-trek. Neither organization has shown the slightest interest in accomodating the other other. Having been on both committees while formulas where being discussed, I proposed a shared standard. Both groups backpedaled away from that idea faster than a tour-de-france racer.

  17. Kohei Yoshida Says:


    >Your self-annihilating devotion to Microsoft is too evident.

    Really? It was not too evident to me just by reading his blog article. BTW I agree with Jody on most points. I too, like Jody, have to deal with both ODF and OOXML filters on a regular basis, though it is for OO.o not for Gnumeric. And my (purely technical) opinion generally is that both formats have their upside and downside, and neither one is better than the other.

    >Filtering will be unnecessary when an authentic Universal Document Format exists.

    If you are referring to ODF, then I will respectfully disagree with you. ODF is IMO not the savior, at least in its present form. The functionality it supports is still limited, and the description of each element in the ODF specification still needs to be improved in order to remove ambiguities on the functionality each element represents. And whether we like it or not, we will still need to import and export both the ODF and OOXML when developing a serious office application, in addition to the binary file formats that we are already having to import and export. That’s just the (sad?) reality of satisfying customer’s needs.

    And IMO, the OOXML format is not that bad, at least not as bad as it’s been publicized to be. Sure it’s not a perfect solution for so-called “interoperability”, but neither is ODF. Both formats need work, and both formats are here to stay.

    BTW, with regard to your argument on (presumably MS format) locking customers data, I too believe that’s a bad thing for the users. No question about it. But I’ve been having hard time selling that concept to end users. It seems as if the users really don’t care, or don’t really realize the bad effect of data lock-in. If you have any tips on how to convince such naive end users, I’d like to know.

  18. Stephane Rodriguez Says:

    I have just taken a look at libgsf-1.14.6, and sure enough, it’s easy to guess why it did not take a month to write it. Unless I have missed something obvious, the entire OPC API is implemented in gsf-open-pkg-utils.c. You are good at hacking, but Part 2 of Ecma 376 contains a wealth of features, conforming rules (Mx.x), which you don’t support at all. For instance, you can’t delete a part, you can’t rename a part, you can’t digitally sign a part, you can’t validate a package. The list goes on and on.

    May be the current implementation you have is such that all of the above is not required yet for the scenario you are willing to support, but please, you want to backpedal a bit the gratuitous statement you made.

  19. Bruce D'Arcus Says:

    Jody: on this:

    “Neither organization has shown the slightest interest in accomodating the other other. Having been on both committees while formulas where being discussed, I proposed a shared standard. Both groups backpedaled away from that idea faster than a tour-de-france racer.”

    At some point you ought you ought to do a post about this; not so much about the politics, but rather the technical possibilities of some “shared standard.” I suspect any possibility for harmonization will have to come from some third party (say ISO? The EU? Dunno). As a start, I’d like to see some formal liaison relationship between the two TCs.

  20. jody Says:

    Stephane : That is the correct place to look for the code. There’s enough there to read and write OOX files with no cryptographic extensions. Which seems more than sufficient for the vast majority of users. In an ideal world OPC would have been split into a distinct standard, and OOX would only have referenced the subset it actually requires.

    – encryption/signing : useful but unnecessary for the 1st round. I can’t read encrypted ODF files either yet.
    – validation : Sounds marginally useful, we could throw together a wrapper to the existing api to verify all the rels, and the content. This is not rocket science, 100? 200? lines max.
    – rename : renaming would be trivial, but completely pointless. The parts are all referenced internally by their types or their ids.

    – delete : This would be a challenge to do it properly. I’ll have to think about it. We’d need to check the content of the refering part to remove the deleted id. Which may not be possible.

    However, none of these capabilities seems terribly important to working on OOX. To spend a month on them before cracking the first content file would be like spending the day polishing your plates before starting to cook dinner. There may be some utility in the process, but there’s lots of more useful things to do.

    I’ll stand by my statement.

  21. jody Says:

    Bruce : To be clear that comment refered only to the formulas, not the spec as a whole.

  22. Stephane Rodriguez Says:

    Since gsf-open-pkg-utils.c isn’t a generic OPC library, there is no point standing with a statement like “On the other hand if it took you a month to write OPC support tools you need better tools.”. That was my point.

    Instead, what it shows is that Microsoft should be embarassed listing Gnumeric in the top applications supporting OOXML. But I guess Microsoft and his supporters have so little ethics it does not matter so much.

  23. Bruce Says:

    Jody: yes, I know.

  24. jody Says:

    Stephane : I’m still not understanding why ‘before I was able to support the first angle bracket of SpreadsheetML, it took me a month’. There’s no rationale that I can see to implement every arcane nook and cranny of the packaging format before doing anything useful. libgsf doesn’t claim to handle everything in OPC, ODF, zip, or OLE2. Yet it seems to cover the vast majority of the usecases required to read and write most documents.

    The ODF advocates seemed happy to trumpet[1] gnumeric’s limited support, how is MS any different, other than our OOX support being somewhat further along than ODF ?

    [1] http://www.oasis-open.org/committees/download.php/21450/oasis_odf_advantages_10dec2006.pdf

  25. Cyrus Mack Says:

    I appear to be missing something. I thought the important part about any document spec or standard was which one can guarantee my right to access data? If you start from the premise that I have the right as an individual to access legally obtained data, then I cannot see anyone advocating OOXML. Since OOXML allows hooks to embedded objects in closed formats, that must mean it’s possible to create documents that require MS Office (if I’m wrong, please do correct me, because that’s my impression) to properly view them.

    I don’t think it’s too much to ask for open source developers to recognize this basic right, and that is why I find this article so disappointing. Do the right thing – pressure Microsoft into ensuring access for all.

    -Cyrus Mack

  26. Barney Says:

    and everyone keeps thinking that MS OOXML is more than a hammer to beat back ODF and Open Office adoption. Why on earth would Microsoft give up any of its 30+% of their profits( from MS Office ) so competitors can read and write their formats? Why after 20 years of constantly manipulating its file formats and using those to keep customers paying for new versions and locking out the competition, would Microsoft do this?

    IMO, this discussion is a waste of everyones time. WTF do we care if MS OOXML is easier to partially implement in Gnumeric than ODF? Just by touching MS OOXML, you are playing their pawn in the only purpose for this exercise. To kill ODF adaption and therefore the threat of Open Office and others as a replacement for Microsoft Office products. MS OOXML is freak’n poison so leave it alone.

  27. orcmid Says:

    Wow, and they say blogs are a conversation! I guess so.

    Jody, I’ve admired your contributions since you provide a leveling influence on the early version of the OpenFormula project.

    You mention ODF spreadsheets and I wonder which ODF spreadsheet formulas you are supporting. Is it basically the OpenOffice.org version or are you being brave and implementing a draft of OpenFormula. I’m not clear on the status of that and which rev of ODF it will finally appear in.

    Do you have any clues to offer?

  28. Jose_x Says:

    In essense, it is an unfair comparison to ODF because as stated OOXML was already basically supported through reverse engineered converters. This has nothing at all to do with the quality of the format or the mistake being made, as duplicate standards effort, if it is accepted when ODF exists already and adheres to existing open standards.

    To give an example, let’s say that there is an author that writes books in a horrible horrible style and in a foreign language. You memorize all the author’s works not knowing better or perhaps in order to be able to get a job that requires knowledge of the author’s works. Later, you are given the dictionary/grammar books to the language and realize what a horrible mess it was, but it is still much easier for you to relate to that work than to something of better quality. Of course, you are an exception. Most other people will not bother with that author unless their marriage depends on it (ie, please please don’t make me).

  29. Jose_x Says:

    >> There’s no rationale that I can see to implement every arcane nook and cranny of the packaging format before doing anything useful. libgsf doesn’t claim to handle everything in OPC, ODF, zip, or OLE2. Yet it seems to cover the vast majority of the usecases required to read and write most documents.

    It may be true that person X speaks English better than French, but if the English is still sloppy, you will have a difficult time getting a job as a writer, interpreter, language teacher, etc. Person X will find work with a client that doesn’t mind words being mistranslated or dropped every now and then or that doesn’t mind producing written works and advertisements that are a little difficult for the audience to follow. A rival from France may fair much better within the same sector. In the end, if the French products are easier to use, the French company will grow in influence and maybe more people will learn to speak french. [Such an anology! Please don’t comment.]

    Person X also cannot argue that English is more consistent, efficient, whatever, than French solely using the logic that s/he speaks English better.

    Closer to home, understand that Microsoft will always have an advantage over groups that refuse to follow a broken spec as close as Microsoft can. Legitimizing this broken spec will legitimize brokeness and put all competing implementations in a position to be faulty right off the bat or else go through disgusting efforts in order to perhaps match the leader of the broken spec implementations (Microsoft).

    [I want to highlight one place where the analogy breaks down. Computers have not trouble switching languages if they are given the correct recipe (meaning if you run the proper app). Humans can’t switch to a new language in a month, much less in microseconds. Taking this into account, it’s now easier to believe that many people would decide to learn/engage in French if that would lead to better communication… all else being equal.]

  30. Brian Jones: Open XML Formats : Links 09-28-2007 Says:

    […] to point out today, some of them are a bit older but I still thought they were good to call out: Jody Goldberg talks about implementing ODF and Open XML – I may have spoke a bit too soon in referring to Gnumeric’s support of OpenXML as being really […]

  31. MSDN Blog Postings » Links 09-28-2007 Says:

    […] Jody Goldberg talks about implementing ODF and Open XML – I may have spoke a bit too soon in referring to Gnumeric’s support of OpenXML as being really rich, but that’s slowly changing. Jody talks about how he was able to pretty easily add in Open XML’s charting recently. There are some great discussions down in the comments of the post. […]

  32. Gnumeric’s view on OOXML « CyberTech Rambler Says:

    […] Gnumeric’s view on OOXML Filed under: Uncategorized — ctrambler @ 4:29 pm Let’s face it, I am not writing a office application, neither is 99.9% of the people discussing this topic. Hence, it is refreshing to see the viewpoint of an Gnumeric spreadsheet writer. […]

  33. Jeffrey Says:

    Apparently the Gnumeric site does not even state that Gnumeric supports OOXML

Leave a Reply