It is a persistent untruth that there is no documentation for these vast binary blobs. MS itself published their internal docs as what I assume was filler material in the 'Excel 97 Developers kit' they were not complete, and have been known to contain errors or miss features. However they are a decent starting point. The OOo folk have also done a wonderful job of writing up the format. The vast majority of the work reading xls has nothing to do with deciphering the bits. The real issue is mapping or figuring out the datastructures that the format implies. If you can use an internal representation that mirrors MS XL import/export is trivial. When there is an impedence mismatch... there is alot more work and bugs.
I'd be interested in getting copies of any file that you have trouble with to see how Gnumeric fairs. Getting good test cases can be very helpful. Our confidentiality policy can apply if desired. Please contact me.
If you're looking for analysis tools in a spreadsheet Gnumeric has alot to offer. Here's a screen shot of just some of the available utilities. The additional worksheet functions (above and beyond MS Excel) are also quite useful.
This is still not to the point where'd I'd like it but it's no longer a bad joke (aka 1.0.x). Have you tried 1.2.x ? If there are still problems please submit samples it helps us to prioritize which areas to focus on. Thanks to the softmaker tests I just added xls import support for gradient backgrounds, things are starting to look reasonably pretty.
Gnumeric is admittedly still pretty weak on the charting side. However, things are improving quickly. Please file a few feature requests to help guide things. 1.3.x has support for error bars now (still need to hook up the xls import for that) and the polar (what xl calls radar) plot engine is in place too. My short term goals are to extend the axis mapping support, and add a gnuplotish implicit iterator feature that is not in XL.
Password protection and array formulas are both reasonably frequent operations I've had to support both for Gnumeric. Some of the, such as 'legend.xls' are quite contrived. I spent last night enabling gradient import from charts to make it that one look better but had the same problem as OOo w.r.t. multiple legend entries. It was not too difficult to see which import flag was causing the problem, but I had no idea how to produce such a chart. Try it yourself in XL. There is no obvious way to produce a legend with fewer elements than series. It took some googling and careful mousework to figure out what they had done to produce it. Gnumeric 1.3.1 will support it, but I'd characterize this test as 'dirty pool' rather than 'fair comparison'
Thanks to the softmaker folk for producing some new test cases for us.
Same goes for spreadsheet 'programming'. If you have to automate some data analysis, write a program. Spreadsheets should be used for quick analysis, or a place to keep your notes for anything not complex enough to warrant a database
I respectfully disagree. Spreadsheet make a very nice interface to complex analytics. Real practitioners do their own calculations on the complex bits and use a spreadsheet front end as a scratch pad, a way to quickly twiddle data. Spreadsheets are not databases, and generally should not be used that way. However, to dismiss them as being merely stedding stones to real databases is to miss the point entirely. They're quite good at lots of other things.
Mitch Kapor's OSA Foundation funds a free spreadsheet test suite
Gnumeric has received a grant from Mitch Kapor (creator of Lotus 1-2-3) to develop an interoperability test suite with leading proprietary competitors. The money will be used as form of bounty to fund the expansion of our existing tests for worksheet functions (eg =SUM, or =ODDFPRICE). Our goal is to ensure that a users data will produce the same results (or better:-) using Gnumeric. The test suite will be in xls format, and will be freely available to all other interested projects.
Exact prices have not been decided as yet, but this is an excellent opporunity for non-coders to help opensource programs, and earn a bit of money too. Specifics to be announced on the mailing lists in the coming weeks.
1) We'll start supporting it. Indeed I've already roughed in a basic framework for Office XP xml for Excel. Its a good deal easier than their binary format, especially given how much of their implementation detail is exposed in the file format.
2) It will not be used very much because old versions of office can't read it (oops the Office 97 install on your secretaries machine is out of date).
3) It will not be used very much because 100 Meg of uncompressed xml takes longer to parse than people with 30Meg of xls want to wait.
Yes is would be very nice if we could stop replicating each others work. However, its difficult to do that in practice because we're all operating on what are in effect completely different platforms. KDE uses entirely different data structures than GNOME, which is in turn different from OO, which is different from mozilla... and MS sits on the sidelines and smiles.
Adding to the technical challenges are the politcal bits. I've writting elements of gnome-office (libgsf) with the specific intent that it be sharable between the different platforms. Why bother rewriting OLE import/export 3 times ? Unfortunatly, that teeny little 'g' is a big problem. The kword folk have accepted the library, but the kspread team seems intent on writing their own. The OO people can't even look at it because 'the mac people would scream when they saw a glib depend'. Its depressing.
For the time being we're stuck. Each of us feels our project can produce the best result in the shortest time. At best the projects can share test suites and documentation. Which is where Mitch Kapor's grant to Gnumeric comes in handy. We're using it to commission a set of tests in xls format (so that we can all read it, even Ms Excel). The other projects are welcome to use it along with all of our other interoperability tests.
I don't see any problems with gnome-office listed in your discussion of gnome's failings. Can you elaborate on any issues you've had with recent versions of Gnumeric, AbiWord, or GNOME-DB ? We're quite interested in constructive feedback.
We'll support it, but will not adopt it as the native format. Frankly I'd rather use xls than the OASIS xml. I've got a few substantive issues with the core structure of the spreadsheet format as proposed by OpenCalc.
Actually it doesn't support it. Only Gnumeric can read encrypted files. There are different levels of encryption/protection in MS Office. OO does not handle files that are actually encrypted because it worred their lawyers.
I contacted the author as soon as the story appeared here on/. asking for details on where Gnumeric had problems, and asking for him to retest with a more current version (1.2 beta1). He responded with
Hal Varian at 9:31 Wed Sept 3, 2003 { speaking of that I went back and checked the 9 files that failed. It turns out { that in 7 of the cases, gnumeric simply displayed a different part of the file { on the opening screen than did excel---scrolling to the left revealed the same { document contents. { This really shouldn't count as an error. I think that I wil lsend in a { correction that Gnumeric actually did much better than it had appeared.
He also confirmed that they were testing appearance, not numberic accuracy or compatibility.
Gnumeric can read encrypted xls files. The mechanism for doing it was largely worked out by Caolan McNamara for.doc files, whose notes are public. He now works on OOo, which does _not_ support encrypted files. Sun/OOo has the knowledge, but clearly their legal team has squashed the notion. You don't mess with MS' legal team lightly. Money may not buy happiness or love, but it can definitely purchase one heck of a lot of lawyers.
We're not copying implementations. The analytics in gnumeric are significantly more accurate than XL on all fronts, and we have quite a few that are not in MS Office. The point of this article is that gnumeric now provides a superset of the analytics in MS Excel. With luck we'll have a 3rd party review confirming this shortly.
We're sharing quite a bit of code with R, and various solver libraries.
Good ideas. Please enter them at bugzilla.gnome.org so that we can keep tack of them. They won't make it for 1.2.0, we're feature frozen, but they could easily go into 1.3
Slashdot Mirror
Gnumeric includes just that
ssconvert foo.xls foo.csv
File a bug, get a patch.
The solver maintainer is reasonably active.
somewhat
... there is alot more work and bugs.
It is a persistent untruth that there is no documentation for these vast binary blobs. MS itself published their internal docs as what I assume was filler material in the 'Excel 97 Developers kit' they were not complete, and have been known to contain errors or miss features. However they are a decent starting point. The OOo folk have also done a wonderful job of writing up the format. The vast majority of the work reading xls has nothing to do with deciphering the bits. The real issue is mapping or figuring out the datastructures that the format implies. If you can use an internal representation that mirrors MS XL import/export is trivial. When there is an impedence mismatch
Gnumeric has solver, goal seek, and iterative expressions.
I'd be interested in getting copies of any file that you have trouble with to see how Gnumeric fairs. Getting good test cases can be very helpful. Our confidentiality policy can apply if desired. Please contact me.
Thanks
We've support XL95 and XL 97/2k/XP for quite a while.
If you're looking for analysis tools in a spreadsheet Gnumeric has alot to offer. Here's a screen shot of just some of the available utilities. The additional worksheet functions (above and beyond MS Excel) are also quite useful.
This is still not to the point where'd I'd like it but it's no longer a bad joke (aka 1.0.x). Have you tried 1.2.x ? If there are still problems please submit samples it helps us to prioritize which areas to focus on. Thanks to the softmaker tests I just added xls import support for gradient backgrounds, things are starting to look reasonably pretty.
This has been supported for quite some time as a compile time option. The 256 is maintained as the default for XL compatibilty.
Gnumeric is admittedly still pretty weak on the charting side. However, things are improving quickly. Please file a few feature requests to help guide things. 1.3.x has support for error bars now (still need to hook up the xls import for that) and the polar (what xl calls radar) plot engine is in place too. My short term goals are to extend the axis mapping support, and add a gnuplotish implicit iterator feature that is not in XL.
Password protection and array formulas are both reasonably frequent operations I've had to support both for Gnumeric. Some of the, such as 'legend.xls' are quite contrived. I spent last night enabling gradient import from charts to make it that one look better but had the same problem as OOo w.r.t. multiple legend entries. It was not too difficult to see which import flag was causing the problem, but I had no idea how to produce such a chart. Try it yourself in XL. There is no obvious way to produce a legend with fewer elements than series. It took some googling and careful mousework to figure out what they had done to produce it. Gnumeric 1.3.1 will support it, but I'd characterize this test as 'dirty pool' rather than 'fair comparison'
Thanks to the softmaker folk for producing some new test cases for us.
Gnumeric has both goal seek and solver. Indeed it has several variants of solver included.
Just my way of hoping some surgery this morning went well.
I respectfully disagree. Spreadsheet make a very nice interface to complex analytics. Real practitioners do their own calculations on the complex bits and use a spreadsheet front end as a scratch pad, a way to quickly twiddle data. Spreadsheets are not databases, and generally should not be used that way. However, to dismiss them as being merely stedding stones to real databases is to miss the point entirely. They're quite good at lots of other things.
Gnumeric has received a grant from Mitch Kapor (creator of Lotus 1-2-3) to develop an interoperability test suite with leading proprietary competitors. The money will be used as form of bounty to fund the expansion of our existing tests for worksheet functions (eg =SUM, or =ODDFPRICE). Our goal is to ensure that a users data will produce the same results (or better
Exact prices have not been decided as yet, but this is an excellent opporunity for non-coders to help opensource programs, and earn a bit of money too. Specifics to be announced on the mailing lists in the coming weeks.
Official announcement here
1) We'll start supporting it. Indeed I've already roughed in a basic framework for Office XP xml for Excel. Its a good deal easier than their binary format, especially given how much of their implementation detail is exposed in the file format.
2) It will not be used very much because old versions of office can't read it (oops the Office 97 install on your secretaries machine is out of date).
3) It will not be used very much because 100 Meg of uncompressed xml takes longer to parse than people with 30Meg of xls want to wait.
Yes is would be very nice if we could stop replicating each others work. However, its difficult to do that in practice because we're all operating on what are in effect completely different platforms. KDE uses entirely different data structures than GNOME, which is in turn different from OO, which is different from mozilla ... and MS sits on the sidelines and smiles.
Adding to the technical challenges are the politcal bits. I've writting elements of gnome-office (libgsf) with the specific intent that it be sharable between the different platforms. Why bother rewriting OLE import/export 3 times ? Unfortunatly, that teeny little 'g' is a big problem. The kword folk have accepted the library, but the kspread team seems intent on writing their own. The OO people can't even look at it because 'the mac people would scream when they saw a glib depend'. Its depressing.
For the time being we're stuck. Each of us feels our project can produce the best result in the shortest time. At best the projects can share test suites and documentation. Which is where Mitch Kapor's grant to Gnumeric comes in handy. We're using it to commission a set of tests in xls format (so that we can all read it, even Ms Excel). The other projects are welcome to use it along with all of our other interoperability tests.
I don't see any problems with gnome-office listed in your discussion of gnome's failings. Can you elaborate on any issues you've had with recent versions of Gnumeric, AbiWord, or GNOME-DB ? We're quite interested in constructive feedback.
We'll support it, but will not adopt it as the native format. Frankly I'd rather use xls than the OASIS xml. I've got a few substantive issues with the core structure of the spreadsheet format as proposed by OpenCalc.
Actually it doesn't support it. Only Gnumeric can read encrypted files. There are different levels of encryption/protection in MS Office. OO does not handle files that are actually encrypted because it worred their lawyers.
I contacted the author as soon as the story appeared here on /. asking for details on where Gnumeric had problems, and asking for him to retest with a more current version (1.2 beta1). He responded with
Hal Varian at 9:31 Wed Sept 3, 2003
{ speaking of that I went back and checked the 9 files that failed. It turns out
{ that in 7 of the cases, gnumeric simply displayed a different part of the file
{ on the opening screen than did excel---scrolling to the left revealed the same
{ document contents.
{ This really shouldn't count as an error. I think that I wil lsend in a
{ correction that Gnumeric actually did much better than it had appeared.
He also confirmed that they were testing appearance, not numberic accuracy or compatibility.
Much as I wish this was true, history disagrees.
.doc files, whose notes are public. He now works on OOo, which does _not_ support encrypted files. Sun/OOo has the knowledge, but clearly their legal team has squashed the notion. You don't mess with MS' legal team lightly. Money may not buy happiness or love, but it can definitely purchase one heck of a lot of lawyers.
Gnumeric can read encrypted xls files. The mechanism for doing it was largely worked out by Caolan McNamara for
We're not copying implementations. The analytics in gnumeric are significantly more accurate than XL on all fronts, and we have quite a few that are not in MS Office. The point of this article is that gnumeric now provides a superset of the analytics in MS Excel. With luck we'll have a 3rd party review confirming this shortly.
We're sharing quite a bit of code with R, and various solver libraries.
Good ideas. Please enter them at bugzilla.gnome.org so that we can keep tack of them. They won't make it for 1.2.0, we're feature frozen, but they could easily go into 1.3
Interesting.
Can you forward a copy of the file with the miss imported fonts ?
Please file a bug about 'replace by'. This is still a beta there is time to polish things before 1.2.0
Yah, it would be nice to have image preview in there. Its a simple project hopefully someone will tackle it.
How is the zoom dialog worse ? bugzilla your complaints please. They'll be easier to track/debate there.