This question has come up before, and I'll give you the same answer.
While we'd all like to 'innovate' (god I hate that word now that MS has abused it) and improve things no one is going to care unless the cost of transition is fairl y low. Before Gnumeric could implement some of its neat new features like dynamic dependencies we had to first implement enough of MS Excel's semantics that people could move their existing data over. That is the key to the real monopoly in Redmond. _They_ control your data. Their products have the content needed to do your work locked up in their semantics, and their binary formats. Before we can start creating a bold new world, we've got to free the hostage content.
It should also be noted that MS has lavished vast resources onto its flagship products. Ignoring all of their work 'because we know better' seems like a fools bet. Over the years I've cursed them frequently, but have also built up a grudging respect for the depth of Excel. It drives me nuts at times, but at least it is a consistent nuts, for some of the murkier corner cases.
Now that Gnumeric has paid the piper, and spent five years understanding what it means to be a spreadsheet we've got more leeway. Which is why we've been able to move so far past XL in terms of quantity and quality of analytics. Hopefully, that tend will continue.
We have tests for accuracy. Speed tends to be more of a 'hmm this is too slow for my taste lets see why' sort of operation. Gnumeric-1.2 is damn fast compared to 1.0, and is easily faster than OOo.
However, I'm not clear on what you're looking for in the context of the solver. 1.1.x has goal seek, and several different optimization algorithms curtesy of various other projects (linear, integer, and non-linear). We're less concerned with XL compatility here (they suck badly). Nor is speed of paramount concern. It seems more important to produce accurate and stable results.
Dunno what else to say. Try it out and bugzilla a report if you see a problem.
Our stated goal in the Gnumeric project is to produce the best spreadsheet available. After some consideration we decided that Gnumeric seems likely to produce that sooner than OpenCalc. OO is an important project, but as a spreadsheet user I have little interest in an office suite. There are quite a few users out there that seem to have similar views.
This is not a winner take all situation. OOo is the right solution for some users. However, Gnumeric is better is several areas already and with some work, we'll move past Excel in more places too.
If you want an Office Suite, by all means use OO. If you want the best possible spreadsheet I'm guessing that people will end up using Gnumeric.
Actually that capability was one of the first things that went into Gnumeric. Its an area we trounce MS Excel on several levels.
- Adding a plugin to gnumeric is trivial. Indeed the vast majority of the functions are in plugins that are demand loaded.
- plugin functions can be written in C (like an XLL but with a much cleaner interface), python, perl, or guile
Docs for python here
I made the claim as clear as possible, and belive it is true. We can accurately reproduce results from every function in the US version of MS Excel.
We'd don't do quite as well comparing evalation techniques, although we're well ahead of OOo in that regard. 1.0.x had support for - iterative evaluation - implicit intersection - and implicit type conversion
In 1.1.x we've added - dynamic dependencies (eg OFFSET, or INDEX) - constructed ranges (A1:INDEX(...)) - and support for implicit iteration for function arguments
That last one is the sole remaining issue as far as I know. I need to finish off support for implicit iteration for operators. Hard to say if it will go in for 1.2.0, probably not (although I've got it partially done), so it will likely wait until 1.3
True, this has been a sticking point for our scripting support. We have not wanted to commmit to a scripting interface that would not allow VBA to be used out of the box. There are several issues with that
1) security. There is absolutely no way in hell that we'll allow vba to run without some sort of sandbox and user intervention to explicitly enable the macros. This will definitely make life more difficult, but perpetuating the nightmare of vba viruses in office docs seems like a terrible idea.
2) Reading and writing the macros. Unlike xls, the vba streams have no public documentation as far as I know. The anti-virus folk appear to have some under various NDAs but I have not seen enough to get a good handle on things. OO and gnumeric can both extract the compressed source code out of the vba streams, but neither of us has a good way of ensuring that will work.
3) In an ideal world we'd be able to extract the p-code rather than the vba source code. That will enable a simple mapping from vba to a more more opensource friendly language like python. The precompiled p-code would remove the need to parse actual vba.
4) If we're actually forced to use VBA, I'm hoping the mono's vb support will be viable as a fall back.
However, even if we find the file format, and we have an interpretter. Supporting it will require a gnumeric scripting api that supports the entire XL api. A large and daunting task. We'll do something smaller and cleaner first, likely based on our experiments in python. To date we've avoided blessing any scripting api because we don't want to offer one api then pull the rug out from under people and change it. An API needs to be stable to be useful. This is high on our list of projects for 1.3.
There appear to be a few functions specific to the asian version of XL, notably
'PHONETIC' that we (and every other opensource spreadsheet) are missing. I've been in contact with some Japanese developers, and we'll hopefully get some support from the Japanese govenrment to get these added as well.
I do not claim that Gnumeric supports all of MS Excel's functionality, and I won't until I feel its true and release gnumeric-2.0. The specific statement was '100% of MS Excel's worksheet functions'
eg =SUM, =VARP, =ODDFPRICE etc
and that is true (although we have recently found some references to a few functions specific to the asian version of MS Excel that we'll have to add). However, for today we support every function in the North American version of XL plus about 80 more.
Gnumeric-1.2 will use stock gnome-2.x libraries. It installs painlessly on rh8 or 9. If you have a nasty test case send me a copy (it can be kept confidential). Gnumeric-1.1.20 is significantly faster than 1.0.x but we can't fix a problem if we haven't seen it.
They're somewhat stuck. The sheer mass of users for older versions of MS Excel limits their ability to change the format in any meaningful way. XL97 was the last time it changed at the core. The amount of shrieking between 95 and 97 was huge. This is one of the reasons Excel will very likely not support more than 256x64k for a long long time. Their file format would implode.
I wouldn't be at all surprised if they have not considered it, but the opensource xls readers tend to be alot more resilient than MS in handling xls. We've had to code defensively sue to poor/missing docs. It will be hard for them to produce anything we (Gnumeric and OO) could not figure out pretty quickly, while still allowing XL97 to handle things.
I've already roughed in a framework to support the XL 2003 xml format. However, we've heard the MS Office / XML chant before. It did not see much common usage, the performance hit with non-trivial files was just too large.
And we can read their encrypted files too, _the horror_.
Thankfully there's not much to worry about here. A few years ago MS published a series of 'MS Excel developer's kit' books. There wasn't much in the way of useful material so for actaully developing extensions to MS Excel available. So, as far as I can tell, Microsoft tried to pad the book with what it figured was some marginally interesting filler, a full set of docs for the xls file format:-)
When I bought the book I was quite irrate at the lack of useful content. It warms my heart all these years later to actually be able to put it to good use.
PS
They also included the full content of the book in various MSDN discs, and on their web site for several years. Then mysteriously pulled it a few years back.
We support wk1, and wk2. There are some specs available for newer versions but I haven't had time to do more work on it. This sort of development is very parallizable. The i/o plugins are completely modular, so if anyone is interested in a new or esoteric format its not at all difficult to get something in place.
This is something I've been working towards for a while now. It will hopefully happen some time early in the 1.3 development cycle. Having a win32 build (and ideally an osx build too) is a very important for the next stage of migration. People migrating to linux will use an app that is compatible, but they're alot more likely to be allowed to use it by central management if it will run on windows too. This is one of the key difference between abiword and Gnumeric. Their community has been bolstered alot by the infusion of windows users and developers.
If anyone is interested in helping with this its largely just a build monkey issue. The underlying libraries are available for win32 (the gtk stack). All we're lacking is someone with the time to patch the last of the build problems, and point out any lingering non portable calls.
It varies. We have a fairly extensive test suite that tries to keep us compatible with MS Excel for the most part. When a discrepancy appears there are 3 possibilities
1) Gnumeric bug which we fix. 2) Better precision in Gnumeric. This is fine. People tend to prefer the right answers when they can be convinced that XL was being silly. eg our VAR, HYPERGEOM, and various financial routines. 3) There is a bug in XL. This is a royal pain in the butt. We end up with 2 functions. The XL 'FOO' that attempts to be bug compatibile, and a fixed G_FOO. We don't get a choice here. People tend to freak out if their imported spreadsheet starts to produce different results. Hopefully in time they can be convinced to use the G_ variants by default.
However, this is definitely an area we take very seriously. The Gnumeric project has received a grant to produce a test suite for open source spreadsheets. I'll announce more details shortly.
In addition to supporting a superset of their worksheet functions, we're also significantly more accurate and stable numericly. With luck I'll have a 3rd party evaluation confirming that within the next few weeks.
> Your sheet is great for what a sheet is good for, simple small data set calculations.
Thanks for the praise. We're aiming a smidge higher than that though. Gnumeric-1.2 should scale nicely to very large data sets, and will even calculate the right answers as opposed to XL.
1) Gnumeric's charting abilities have historically been pathetic (I wrote the guppi wrapper so I'm allowed to tell it like it is). Guppi was a nice piece of work, with lots of fantastic features. None of which were visible to a Gnumeric-1.0.x user. Please do not judge us by that.
2) MS Excel's charting IMHO sucks badly. It is definitely the weakest part of their product. Which makes (1) hurt even more. There are definitely projects out there that already make data visualization and analysis much easier that the highly polished kludge that XL uses. Don't get me wrong, the interface to the mess has seen alot of work. Which is what you'd expect from a product with 100s of millions of beta testers (aka customers). Look at Splus/R, grace, or any of the pletora of analysis tools out there and XL's byzantine mess will instantly seem silly. We can definitely do better.
Of course we first need to support XL style charts smoothly, so that people can migrate, but this is definitely high on the target list of area to 'innovate'.
I do not claim that Gnumeric supports 100% of the features in MS Excel. That will not be until version 2.0 ('aka Extend') which I'd like to see go out within the next year. The language in the release notes was very explicit
"100% of the worksheet functions"
That refers only to the functions callable from expressions in cells.
The Gnumeric team has been fairly anal about never claiming to support a feature that was not complete. Our Charting engine has long been a source of pain that never quite managed to find its niche. Which is what has delayed the 1.2 release for almost a year. Our new engine is targetted explititly at supported a superset of MS Excel's charting so that, like the rest of Gnumeric, things look just right when you import from xls. I've spent time ensuring that things are practically pixel perfect given the right fonts.
We've supported reading and writing cell comments (memos) from xls95 for years. 1.1.20 adds that capability for 97/2k/XP too. Not sure what you mean by 'graphics embedded in a cell'. Please file a bug report with more details and we can keep track of the request.
Its a question of resource allocation. For any time we spend polishing our xls import export we get access to the installed base of MS Office. Whereas time spent on OOo's formats yields a much smaller number. Given more resources we'd spend more time on it, but for now I threw together an importer in a couple of weekends, and have only received one bug report in 6 months. given the documentation for the OOo format, and more importantly the existance of readable code that impliments it, it would be a simple project for someone to improve our support.
Yes, 1.1.x supports exporting to the newer 97/2k/XP formats.
Drop by the mailing list or #gnumeric on irc.gnome.org to meet the gang.
Re:Gnumeric and non-English Excel
on
Gnumeric Turns 5
·
· Score: 3, Informative
We now use utf8 internally and pango to display content. I did a fair amount of testing last year importing various asian languages, and have recently started testing hebrew to validate the R to L support. So things should be on pretty solid ground for 1.2.
Our core file format is utf8 encoded xml, so its not really an issue.
Slashdot Mirror
This question has come up before, and I'll give you the same answer.
While we'd all like to 'innovate' (god I hate that word now that MS has abused it) and improve things no one is going to care unless the cost of transition is fairl y low. Before Gnumeric could implement some of its neat new features like dynamic dependencies we had to first implement enough of MS Excel's semantics that people could move their existing data over. That is the key to the real monopoly in Redmond. _They_ control your data. Their products have the content needed to do your work locked up in their semantics, and their binary formats. Before we can start creating a bold new world, we've got to free the hostage content.
It should also be noted that MS has lavished vast resources onto its flagship products. Ignoring all of their work 'because we know better' seems like a fools bet. Over the years I've cursed them frequently, but have also built up a grudging respect for the depth of Excel. It drives me nuts at times, but at least it is a consistent nuts, for some of the murkier corner cases.
Now that Gnumeric has paid the piper, and spent five years understanding what it means to be a spreadsheet we've got more leeway. Which is why we've been able to move so far past XL in terms of quantity and quality of analytics. Hopefully, that tend will continue.
We have tests for accuracy. Speed tends to be more of a 'hmm this is too slow for my taste lets see why' sort of operation. Gnumeric-1.2 is damn fast compared to 1.0, and is easily faster than OOo.
However, I'm not clear on what you're looking for in the context of the solver.
1.1.x has goal seek, and several different optimization algorithms curtesy of various other projects (linear, integer, and non-linear). We're less concerned with XL compatility here (they suck badly). Nor is speed of paramount concern. It seems more important to produce accurate and stable results.
Dunno what else to say. Try it out and bugzilla a report if you see a problem.
Our stated goal in the Gnumeric project is to produce the best spreadsheet available. After some consideration we decided that Gnumeric seems likely to produce that sooner than OpenCalc. OO is an important project, but as a spreadsheet user I have little interest in an office suite. There are quite a few users out there that seem to have similar views.
This is not a winner take all situation. OOo is the right solution for some users. However, Gnumeric is better is several areas already and with some work, we'll move past Excel in more places too.
If you want an Office Suite, by all means use OO. If you want the best possible spreadsheet I'm guessing that people will end up using Gnumeric.
Actually that capability was one of the first things that went into Gnumeric. Its an area we trounce MS Excel on several levels. - Adding a plugin to gnumeric is trivial. Indeed the vast majority of the functions are in plugins that are demand loaded. - plugin functions can be written in C (like an XLL but with a much cleaner interface), python, perl, or guile Docs for python here
I made the claim as clear as possible, and belive it is true.
We can accurately reproduce results from every function in the US version of MS Excel.
We'd don't do quite as well comparing evalation techniques, although we're well ahead of OOo in that regard. 1.0.x had support for
- iterative evaluation
- implicit intersection
- and implicit type conversion
In 1.1.x we've added
- dynamic dependencies (eg OFFSET, or INDEX)
- constructed ranges (A1:INDEX(...))
- and support for implicit iteration for function arguments
That last one is the sole remaining issue as far as I know. I need to finish off support for implicit iteration for operators. Hard to say if it will go in for 1.2.0, probably not (although I've got it partially done), so it will likely wait until 1.3
True, this has been a sticking point for our scripting support. We have not wanted to commmit to a scripting interface that would not allow VBA to be used out of the box. There are several issues with that
1) security.
There is absolutely no way in hell that we'll allow vba to run without some sort of sandbox and user intervention to explicitly enable the macros. This will definitely make life more difficult, but perpetuating the nightmare of vba viruses in office docs seems like a terrible idea.
2) Reading and writing the macros. Unlike xls, the vba streams have no public documentation as far as I know. The anti-virus folk appear to have some under various NDAs but I have not seen enough to get a good handle on things. OO and gnumeric can both extract the compressed source code out of the vba streams, but neither of us has a good way of ensuring that will work.
3) In an ideal world we'd be able to extract the p-code rather than the vba source code. That will enable a simple mapping from vba to a more more opensource friendly language like python. The precompiled p-code would remove the need to parse actual vba.
4) If we're actually forced to use VBA, I'm hoping the mono's vb support will be viable as a fall back.
However, even if we find the file format, and we have an interpretter. Supporting it will require a gnumeric scripting api that supports the entire XL api. A large and daunting task. We'll do something smaller and cleaner first, likely based on our experiments in python. To date we've avoided blessing any scripting api because we don't want to offer one api then pull the rug out from under people and change it. An API needs to be stable to be useful. This is high on our list of projects for 1.3.
Good point.
There appear to be a few functions specific to the asian version of XL, notably
'PHONETIC'
that we (and every other opensource spreadsheet) are missing. I've been in contact with some Japanese developers, and we'll hopefully get some support from the Japanese govenrment to get these added as well.
I do not claim that Gnumeric supports all of MS Excel's functionality, and I won't until I feel its true and release gnumeric-2.0. The specific statement was
'100% of MS Excel's worksheet functions'
eg =SUM, =VARP, =ODDFPRICE etc
and that is true (although we have recently found some references to a few functions specific to the asian version of MS Excel that we'll have to add). However, for today we support every function in the North American version of XL plus about 80 more.
Gnumeric-1.2 will use stock gnome-2.x libraries. It installs painlessly on rh8 or 9. If you have a nasty test case send me a copy (it can be kept confidential). Gnumeric-1.1.20 is significantly faster than 1.0.x but we can't fix a problem if we haven't seen it.
They're somewhat stuck. The sheer mass of users for older versions of MS Excel limits their ability to change the format in any meaningful way. XL97 was the last time it changed at the core. The amount of shrieking between 95 and 97 was huge. This is one of the reasons Excel will very likely not support more than 256x64k for a long long time. Their file format would implode.
I wouldn't be at all surprised if they have not considered it, but the opensource xls readers tend to be alot more resilient than MS in handling xls. We've had to code defensively sue to poor/missing docs. It will be hard for them to produce anything we (Gnumeric and OO) could not figure out pretty quickly, while still allowing XL97 to handle things.
I've already roughed in a framework to support the XL 2003 xml format. However, we've heard the MS Office / XML chant before. It did not see much common usage, the performance hit with non-trivial files was just too large.
And we can read their encrypted files too, _the horror_.
:-)
Thankfully there's not much to worry about here. A few years ago MS published a series of 'MS Excel developer's kit' books. There wasn't much in the way of useful material so for actaully developing extensions to MS Excel available. So, as far as I can tell, Microsoft tried to pad the book with what it figured was some marginally interesting filler, a full set of docs for the xls file format
When I bought the book I was quite irrate at the lack of useful content. It warms my heart all these years later to actually be able to put it to good use.
PS
They also included the full content of the book in various MSDN discs, and on their web site for several years. Then mysteriously pulled it a few years back.
We support wk1, and wk2. There are some specs available for newer versions but I haven't had time to do more work on it. This sort of development is very parallizable. The i/o plugins are completely modular, so if anyone is interested in a new or esoteric format its not at all difficult to get something in place.
If anyone is interested please contact me.
Soon.
This is something I've been working towards for a while now. It will hopefully happen some time early in the 1.3 development cycle. Having a win32 build (and ideally an osx build too) is a very important for the next stage of migration. People migrating to linux will use an app that is compatible, but they're alot more likely to be allowed to use it by central management if it will run on windows too. This is one of the key difference between abiword and Gnumeric. Their community has been bolstered alot by the infusion of windows users and developers.
If anyone is interested in helping with this its largely just a build monkey issue. The underlying libraries are available for win32 (the gtk stack). All we're lacking is someone with the time to patch the last of the build problems, and point out any lingering non portable calls.
It varies. We have a fairly extensive test suite that tries to keep us compatible with MS Excel for the most part. When a discrepancy appears there are 3 possibilities
1) Gnumeric bug which we fix.
2) Better precision in Gnumeric. This is fine. People tend to prefer the right answers when they can be convinced that XL was being silly. eg our VAR, HYPERGEOM, and various financial routines.
3) There is a bug in XL. This is a royal pain in the butt.
We end up with 2 functions. The XL 'FOO' that attempts to be bug compatibile, and a fixed G_FOO. We don't get a choice here. People tend to freak out if their imported spreadsheet starts to produce different results. Hopefully in time they can be convinced to use the G_ variants by default.
However, this is definitely an area we take very seriously. The Gnumeric project has received a grant to produce a test suite for open source spreadsheets. I'll announce more details shortly.
In addition to supporting a superset of their worksheet functions, we're also significantly more accurate and stable numericly. With luck I'll have a 3rd party evaluation confirming that within the next few weeks.
> Your sheet is great for what a sheet is good for, simple small data set calculations.
Thanks for the praise. We're aiming a smidge higher than that though. Gnumeric-1.2 should scale nicely to very large data sets, and will even calculate the right answers as opposed to XL.
I'd like to address two issues here.
1) Gnumeric's charting abilities have historically been pathetic (I wrote the guppi wrapper so I'm allowed to tell it like it is). Guppi was a nice piece of work, with lots of fantastic features. None of which were visible to a Gnumeric-1.0.x user. Please do not judge us by that.
2) MS Excel's charting IMHO sucks badly. It is definitely the weakest part of their product. Which makes (1) hurt even more. There are definitely projects out there that already make data visualization and analysis much easier that the highly polished kludge that XL uses. Don't get me wrong, the interface to the mess has seen alot of work. Which is what you'd expect from a product with 100s of millions of beta testers (aka customers). Look at Splus/R, grace, or any of the pletora of analysis tools out there and XL's byzantine mess will instantly seem silly. We can definitely do better.
Of course we first need to support XL style charts smoothly, so that people can migrate, but this is definitely high on the target list of area to 'innovate'.
I do not claim that Gnumeric supports 100% of the features in MS Excel. That will not be until version 2.0 ('aka Extend') which I'd like to see go out within the next year. The language in the release notes was very explicit
"100% of the worksheet functions"
That refers only to the functions callable from expressions in cells.
The Gnumeric team has been fairly anal about never claiming to support a feature that was not complete. Our Charting engine has long been a source of pain that never quite managed to find its niche. Which is what has delayed the 1.2 release for almost a year. Our new engine is targetted explititly at supported a superset of MS Excel's charting so that, like the rest of Gnumeric, things look just right when you import from xls. I've spent time ensuring that things are practically pixel perfect given the right fonts.
We've supported reading and writing cell comments (memos) from xls95 for years. 1.1.20 adds that capability for 97/2k/XP too. Not sure what you mean by 'graphics embedded in a cell'. Please file a bug report with more details and we can keep track of the request.
Its a question of resource allocation. For any time we spend polishing our xls import export we get access to the installed base of MS Office. Whereas time spent on OOo's formats yields a much smaller number. Given more resources we'd spend more time on it, but for now I threw together an importer in a couple of weekends, and have only received one bug report in 6 months. given the documentation for the OOo format, and more importantly the existance of readable code that impliments it, it would be a simple project for someone to improve our support.
The 1.1.x tree can read sxc somewhat and will hopefully get an exporter for the format early in 1.3.
screenshots are out of date. They correspond to the 1.0.x stable series rather than the friendly new 1.1.x versions.
However, we'd love to get more UI review.
Ok, so I cheated a bit :-)
The modern version is indeed const.
Yes, 1.1.x supports exporting to the newer 97/2k/XP formats.
Drop by the mailing list or #gnumeric on irc.gnome.org to meet the gang.
We now use utf8 internally and pango to display content. I did a fair amount of testing last year importing various asian languages, and have recently started testing hebrew to validate the R to L support. So things should be on pretty solid ground for 1.2.
Our core file format is utf8 encoded xml, so its not really an issue.