I am somewhat down on ODF this week because the irritation of trying to implement it is fresh. OOX pisses me off just as much when working there:-) Which, at the end of the day, is the point. Both formats have serious flaws. Flaws that reflect their parentage. I don't see either as being far enough along to have been blessed as international standards. However, OOX easily surpasses that bar set by ODF 1.0. We're apply a double standard (pun fully intended).
1) OOX was easier to deal for several reasons. Yes, some of it was because Gnumeric's data structures were designed around the Excel UI and hence matched nicely with the MS file formats. However, that was only part of the issue. SpreadsheetML was clearly written by the Excel team, whereas the ODF spreadsheet functionality frequently feels like it was written by XML document people. ODF is missing critical spreadsheet features like shared expressions and strings. It took me about 12 hours of hacking to implement chart import for OOX to a reasonable level. I've just wasted 48 hours on ODF chart import trying to reverse engineer how to allocate data to charts. That kind of ratio is not the way to make people love ODF.
2) 'very rich support'. This depends on how you parse things. Our OOX importer was more advanced that the ODF importer after about 1 week of effort. At the time Brian made his comment the _exporter_ was not terribly advanced. That is being rectified for the upcoming gnumeric 1.8.x release. Calling gnumeric's round trip capabilities for OOX 'very rich' was an exaggeration, but it's a stretch to call it a complete lie. On the flip side, ODF proponents seem happy to tout our suboptimal ODF implementation. Both filters are improving, but it's more than a bit hypocritical to try and complain about OOX and laud ODF for filters of comparable quality.
While working for Novell I was able to join both OASIS for ODF and ECMA for OOX. After leaving the OO.o development team at Novell to return to other work I lost both memberships and had to scramble to rejoin. Maintaing Gnumeric is a hobby, and my current employer is not involved in the standardization process. Paying out the membership costs of either OASIS or ECMA was not going to happen at the personal or corporate level. Thankfully there was a non-profit tier available, and the GNOME Foundation generously sponsored me to re-join ECMA and TC45 to continue to participate in the the specification process. After spending the last 8 years playing proctologist to every spreadsheet format around, and complaining loudly at the poor quality of documentation for XLS it seems ridiculous to pass up the opportunity to engage MS, and ensure that the spec of their new format was more detailed than previous efforts.
The FLOSS community is going to need to implement importers for both formats to help our users, and I'll be happiest when both OOX and ODF are significantly clearer. 5700 pages of OOX is too _short_, Likewise the 700 + 300 (Open formula) in ODF is far too short. Lets double the size of OOX (although with better formatting the number of pages would likely be unchanged), and lets quadruple the level of detail in ODF to get it into a useful state. I only wish that ODF had undergone a fraction of the review that OOX has seen.
This is not about GNOME endorsing OOX, it's about GNOME doing the work necessary for users. There should be reps from Sun's OO.o team on the ECMA TC, and MS reps in the ODF meetings. The goal of this process is to produce useful documentation, and it takes an implementor to know where the really important details are. It hardly seems in the best interest of the FLOSS community to leave the standardization efforts up to corporate interests at Microsoft, Sun, or IBM.
The headlines are ripe with discussions of the northern cap shrinking.
Apparently it is less interesting that the southern cap has
reached record size and the average temperature has come down.
When working on filters for gnumeric my standard approach is to write a collection of test files tweaking various pieces of the format (see gnumeric/samples dir in svn). I've yet to hit any significant binary blobs that are not also in ODF (eg emf/wmf images). Indeed, while reviewing parts of Spreadsheetml I haven't come across significant binary content. There is lot's to complain about in OOX without our making up random stuff.
You're getting close. No, I do not say OOX is a great format. There are lots of places it could have been improved. However, the same is true of ODF. Gnumeric makes a lovely test bed for comparison. We're a neutral 3rd party implementer trying to handle both of these specs. Once the politics have been removed there are two unpleasant truths that the ODF-cheering section doesn't want to hear.
1) like OOX, ODF is underdocumented, and has significant limitations. 2) OOX, despite it's various flaws, is better documented, and in some ways superior to ODF.
There is a fundamental hypocrisy that is unfortunate. We should be discussing the limitations of each standard and how to improve them but at the core it is my belief that if ODF is acceptable as a standard, then so is OOX. Take both or take neither, but to chose just one is nonsense.
Can you supply an example of where gnumeric does not update references as expected ? We know of a few corner cases involving moving the corner of a rectngular region, but on the whole we should cover everything. Please report any problem you find.
The upcoming 1.4.0 release (due in the next few days) supports a --without-gnome configure time option that decreases functionality (no gnome-vfs means no direct http support), but still works nicely as a spreadsheet. We use this for our win32 port.
Have you tried any of the 1.2.x releases ? (current is 1.2.13) I've been doing alot of work on the chart importer and engine. Although we're limited to 2d plots right now, we should support all of the standards very well. In many ways we're more compatible with ms XL for corner cases like, missing values and implicit conversions. If you ever find a workbook that Gnumeric can not load properly please _contact us_ There are too many features to test all of them directly, we are dependent on people to report problems.
Unfortunately it's a non-trivial amount of work to write a vba clone. Not impossible by any means, but it does require a community to do it. We started the gb project years ago, but it faded away without real progress. I'm currently pinning my hopes on mono and it's basic implementation.
Frankly I prefer MS Excel's xml to OOo's OASIS xml. We've got parsers for both in Gnumeric, although neither has seen alot of testing. The oasis format irritated my because it felt like it had been designed by the xml people rather than the spreadsheet people. For example, there is no explicit cell addresses in the content. The structure is implicit in the ordering. This means that people can't easily lookup the content of a specific cell without at least a moderate amount of parsing. It also completely ignores share expressions, a huge performance loss.
A bulleted list ?/me scratches head I'm not sure what you mean. Send a recipe for how to do this in MS Excel to me (jody@gnome.org) and I'll see about adding it to Gnumeric.
We run on osx www.openosx.com and cvs head is ready and all of its dependencies compile under win32 with gtk-2.4.x. We're very very close to getting a release out.
I've fixed a few of the other issues in 1.2.13. CVS head has support for the radar plots too. We still don't handle word art, and our gradients in charts are a bit different. Thanks to the planmaker folk for the additional test cases. I don't consider them terribly indicative of xls import quality on the whole, we already have lots of things that failed or crashed planmaker, but it was interesting.
1) not open source 2) They certainly have good filters for such a young project, but the claim of _better_ seems questionable. The test cases they provide are not consistent with my testing of the beta.
XLS and OLE2 are not patented. You're probably confusing them with the reports of the xml schema being patented. The binary formats that are still used in the vast majority of cases had parts of their specs published long ago. There was alot of work figuring out the undocumented, or incorrectly documented bits, and lots still to do. However, I have not heard of any patents.
I'd be interested in any workbooks you've got that don't import smoothly. We (Gnumeric) are doing a fair amount of work chart import/export right now. A test case will ensure your pet feature is handled.
This is a difficult proposition and a question that the Gnumeric team has wrestled with. OOo is a strong community and does excellent work. Unfortunately, it has no incentive to share. It takes work to split out interesting subsystems
- EMF rendering
- OLE2 in/out the OOo developers have other things to do. None of the other projects get to cross polinate. This makes it an all or nothing proposition. In contrast gnumeric has spawned several supporting projects (eg libgsf) that are used by other projects (abiword, kword...).
Which is why we've worked so hard on seemless import/export of xls, and try to provide a strict superset of Ms Excel features when possible. Users can optionally even use XL style keybindings so that the finger feel remains the same.
Not really feasible. The Ms Excel xls format has been mostly frozen for years. Microsoft needs to contend with all the ancient versions of XL that are still in use. I'm betting this is a significant part of the reason that they have not expanded the number of cols/rows it would take a major shift in the file format.
Even if they did sit down and work out ways to crash the various competing importers the advantage would be short lived. It's quite easy to debug a crash/failure in your own code. For me it's much harder to export xls, figuring out why Excel is crashing is an irritating process of bit twiddling.
Slashdot Mirror
I am somewhat down on ODF this week because the irritation of trying to implement it is fresh. OOX pisses me off just as much when working there :-)
Which, at the end of the day, is the point. Both formats have serious flaws. Flaws that reflect their parentage. I don't see either as being far enough along to have been blessed as international standards. However, OOX easily surpasses that bar set by ODF 1.0. We're apply a double standard (pun fully intended).
1) OOX was easier to deal for several reasons. Yes, some of it was because Gnumeric's data structures were designed around the Excel UI and hence matched nicely with the MS file formats. However, that was only part of the issue. SpreadsheetML was clearly written by the Excel team, whereas the ODF spreadsheet functionality frequently feels like it was written by XML document people. ODF is missing critical spreadsheet features like shared expressions and strings. It took me about 12 hours of hacking to implement chart import for OOX to a reasonable level. I've just wasted 48 hours on ODF chart import trying to reverse engineer how to allocate data to charts. That kind of ratio is not the way to make people love ODF.
2) 'very rich support'. This depends on how you parse things. Our OOX importer was more advanced that the ODF importer after about 1 week of effort. At the time Brian made his comment the _exporter_ was not terribly advanced. That is being rectified for the upcoming gnumeric 1.8.x release. Calling gnumeric's round trip capabilities for OOX 'very rich' was an exaggeration, but it's a stretch to call it a complete lie. On the flip side, ODF proponents seem happy to tout our suboptimal ODF implementation. Both filters are improving, but it's more than a bit hypocritical to try and complain about OOX and laud ODF for filters of comparable quality.
While working for Novell I was able to join both OASIS for ODF and ECMA for OOX. After leaving the OO.o development team at Novell to return to other work I lost both memberships and had to scramble to rejoin. Maintaing Gnumeric is a hobby, and my current employer is not involved in the standardization process. Paying out the membership costs of either OASIS or ECMA was not going to happen at the personal or corporate level. Thankfully there was a non-profit tier available, and the GNOME Foundation generously sponsored me to re-join ECMA and TC45 to continue to participate in the the specification process. After spending the last 8 years playing proctologist to every spreadsheet format around, and complaining loudly at the poor quality of documentation for XLS it seems ridiculous to pass up the opportunity to engage MS, and ensure that the spec of their new format was more detailed than previous efforts.
My personal opinion (not speaking for the GNOME foundation or past or present employers) is that both specs should be standards
http://www.gnome.org/~jody/files/2007-ON-Linux-Beyond-ISO-Dome.pdf
The FLOSS community is going to need to implement importers for both formats to help our users, and I'll be happiest when both OOX and ODF are significantly clearer. 5700 pages of OOX is too _short_, Likewise the 700 + 300 (Open formula) in ODF is far too short. Lets double the size of OOX (although with better formatting the number of pages would likely be unchanged), and lets quadruple the level of detail in ODF to get it into a useful state. I only wish that ODF had undergone a fraction of the review that OOX has seen.
This is not about GNOME endorsing OOX, it's about GNOME doing the work necessary for users. There should be reps from Sun's OO.o team on the ECMA TC, and MS reps in the ODF meetings. The goal of this process is to produce useful documentation, and it takes an implementor to know where the really important details are. It hardly seems in the best interest of the FLOSS community to leave the standardization efforts up to corporate interests at Microsoft, Sun, or IBM.
The headlines are ripe with discussions of the northern cap shrinking. Apparently it is less interesting that the southern cap has reached record size and the average temperature has come down.
When working on filters for gnumeric my standard approach is to write a collection of test files tweaking various pieces of the format (see gnumeric/samples dir in svn). I've yet to hit any significant binary blobs that are not also in ODF (eg emf/wmf images). Indeed, while reviewing parts of Spreadsheetml I haven't come across significant binary content. There is lot's to complain about in OOX without our making up random stuff.
You're getting close. No, I do not say OOX is a great format. There are lots of places it could have been improved. However, the same is true of ODF. Gnumeric makes a lovely test bed for comparison. We're a neutral 3rd party implementer trying to handle both of these specs. Once the politics have been removed there are two unpleasant truths that the ODF-cheering section doesn't want to hear.
1) like OOX, ODF is underdocumented, and has significant limitations.
2) OOX, despite it's various flaws, is better documented, and in some ways superior to ODF.
There is a fundamental hypocrisy that is unfortunate. We should be discussing the limitations of each standard and how to improve them but at the core it is my belief that if ODF is acceptable as a standard, then so is OOX. Take both or take neither, but to chose just one is nonsense.
We're working on making them runtime extensible.
Can you supply an example of where gnumeric does not update references as expected ? We know of a few corner cases involving moving the corner of a rectngular region, but on the whole we should cover everything. Please report any problem you find.
The upcoming 1.4.0 release (due in the next few days) supports a --without-gnome configure time option that decreases functionality (no gnome-vfs means no direct http support), but still works nicely as a spreadsheet. We use this for our win32 port.
Have you tried any of the 1.2.x releases ? (current is 1.2.13) I've been doing alot of work on the chart importer and engine. Although we're limited to 2d plots right now, we should support all of the standards very well. In many ways we're more compatible with ms XL for corner cases like, missing values and implicit conversions. If you ever find a workbook that Gnumeric can not load properly please _contact us_ There are too many features to test all of them directly, we are dependent on people to report problems.
Thanks
Sure. They're publicly avaialble on the webn fo.shtml
http://www.gnome.org/projects/gnumeric/function-i
We've got lots of other tests that we have not run through planmaker. Would you be interested in swapping test suites ?
Please send me the files. We're always looking for test cases.
Our standard confidentiallity policy can apply if necessary.
Gnumeric includes a super set of MS Excel's statistics support
Additionally the analytics it includes are of significantly better quality.
http://www.csdassn.org/software_reports.html
amen
Unfortunately it's a non-trivial amount of work to write a vba clone. Not impossible by any means, but it does require a community to do it. We started the gb project years ago, but it faded away without real progress. I'm currently pinning my hopes on mono and it's basic implementation.
- download gnumeric
- edit SHEET_MAX_ROWS in gnumeric.h
- compile
Frankly I prefer MS Excel's xml to OOo's OASIS xml. We've got parsers for both in Gnumeric, although neither has seen alot of testing. The oasis format irritated my because it felt like it had been designed by the xml people rather than the spreadsheet people. For example, there is no explicit cell addresses in the content. The structure is implicit in the ordering. This means that people can't easily lookup the content of a specific cell without at least a moderate amount of parsing. It also completely ignores share expressions, a huge performance loss.
A bulleted list ? /me scratches head
I'm not sure what you mean. Send a recipe for how to do this in MS Excel to me (jody@gnome.org) and I'll see about adding it to Gnumeric.
We run on osx www.openosx.com
and cvs head is ready and all of its dependencies compile under win32 with gtk-2.4.x. We're very very close to getting a release out.
I've fixed a few of the other issues in 1.2.13. CVS head has support for the radar plots too. We still don't handle word art, and our gradients in charts are a bit different. Thanks to the planmaker folk for the additional test cases. I don't consider them terribly indicative of xls import quality on the whole, we already have lots of things that failed or crashed planmaker, but it was interesting.
1) not open source
2) They certainly have good filters for such a young project, but the claim of _better_ seems questionable. The test cases they provide are not consistent with my testing of the beta.
XLS and OLE2 are not patented.
You're probably confusing them with the reports of the xml schema being patented. The binary formats that are still used in the vast majority of cases had parts of their specs published long ago. There was alot of work figuring out the undocumented, or incorrectly documented bits, and lots still to do. However, I have not heard of any patents.
I'd be interested in any workbooks you've got that don't import smoothly. We (Gnumeric) are doing a fair amount of work chart import/export right now. A test case will ensure your pet feature is handled.
This is a difficult proposition and a question that the Gnumeric team has wrestled with. OOo is a strong community and does excellent work. Unfortunately, it has no incentive to share. It takes work to split out interesting subsystems ...).
- EMF rendering
- OLE2 in/out
the OOo developers have other things to do. None of the other projects get to cross polinate. This makes it an all or nothing proposition. In contrast gnumeric has spawned several supporting projects (eg libgsf) that are used by other projects (abiword, kword
Which is why we've worked so hard on seemless import/export of xls, and try to provide a strict superset of Ms Excel features when possible. Users can optionally even use XL style keybindings so that the finger feel remains the same.
Not really feasible. The Ms Excel xls format has been mostly frozen for years. Microsoft needs to contend with all the ancient versions of XL that are still in use. I'm betting this is a significant part of the reason that they have not expanded the number of cols/rows it would take a major shift in the file format.
Even if they did sit down and work out ways to crash the various competing importers the advantage would be short lived. It's quite easy to debug a crash/failure in your own code. For me it's much harder to export xls, figuring out why Excel is crashing is an irritating process of bit twiddling.