I have spent a long long time trying to properly import MS Excel documents into Gnumeric. This requires reading serveral layers of formats to extract the raw data.
- ole : to get access to the files - biff : to access the primary records - escher : to handle embedded objects plus other bits further up the food chain, like emf/wmf.
Reading the raw data is the least of our concerns. Understanding what it represents is quite another thing. A few years back MS tried to pull a fast one. They published some 'Developer Guides' for MS Excel (4 5 20 of some integer if they do not document how to map from the index to a colour. I'd estimate that the docs covered no more than 1/2 of the actual format.
Sticking all of the information into xml doesn't solve the problem. It just ameliorates the lower level pain. We still need to document, _clearly_ document the precise meaning of each field along with their relationships. XML makes verbosity/size and issue alot sooner than binary formats. It is easy to claim that compressed xml is about the same size as uncompressed xls, but that is not a valid comparison. Compressing the format makes it alot less useful (no random access). It is also a perfomance nightmare. In Gnumeric we've had to give alot of thought to our xml format to minimize the amount of replicated information. This makes it much faster to read, but makes it more opaque.
Even if we can magicly hurdle all of these issue there is still the fundamental point that a file format is dump of an application's state. That state includes your data, and a pinch of the application specific wrapping. Presumably your data can travel to other similar apps (not necessarily true for spreadsheet functions) but the application data is going to depend alot on how _this_ version of this application perceives things. If another app wants to read that data it needs to support a super set of the originating features, and must be able to map (quickly) to the new representation.
So, just tossing some docs into the public domain are probably not going to do much. Heck we've had docs for most of the lotus wk* formats for 2 years, but have never had time to write an importer never minds an exporter. Anyone want to help ?
Re:Gnome should stick to the GUI and System Tools
on
Gnumeric 1.0 Has Arrived
·
· Score: 4, Informative
Gnumeric started 3.5 years ago well before StarOffice began its transition to OpenSource. Our goal has always been to produce a the best possible spreadsheet, and we chose the GNOME project as our toolkit. I've looked at the source for kspread and attempted to borrow code from OpenCalc and have concluded that while they each have their strengths, Gnumeric's architecture feels like it is a better basis for development. Try loading large or complicated workbooks into either and compare for yourself.
The GNOME project has a well developed and evolving toolkit specificly _because_ of projects like Gnumeric, Evolution and Galeon. A toolkit without developers does not progress very quickly.
While your goal is noble I think you miss an important point. People are only willing to switch to something new IF the transition is relatively painless. It is not an accident that MS Excel (tm) includes lots of old and ignored lotus-1-2-3 compatibility utilities. We can have the most fantastic spreadsheet in history, and it would still be largely ignored unless there is an easy way to convert XL files to/from Gnumeric. Which is pretty much the plan. Once we have a spreadsheet that can interact well enough with XL people can extend it to add all the lovely innovations they can think of. Remember the MS mantra 'Embrace, Extend,...'
Re:Who does use this thing professionally ?
on
Gnumeric 1.0 Has Arrived
·
· Score: 3, Informative
Several of the core Gnumeric developers use it for real work, and based on our bug reports so do many other people. Most of us are working on the project because we are so familiar with the pain and the power of MS Excel (tm). When it works it is a hugely powerful piece of work, but when it doesn't you are up a creek. The 1.0 version of Gnumeric will not replace MS Excel (tm) for a power user. However, it should be sufficient for most day to day users. The goal is to produce a platform that will be able to do all the things we're used to, and hopefully we're on the right track.
I don't know what version you tried but we should be damn near pixel perfect for borders, patterns, formats, content and values. Sheet objects like buttons and drawings still need work.
IMO people who discuss 'Retaliation' and 'Measured responses' miss the point. The former is nothing more than a polite phrase for Revenge, and the latter is ineffective. Terrorists have moved the playing field away from the civilized world's strength, military power, and moved it into it an area of weakness, fear. As a weapon fear is currently a very one sided arsenal. We all felt a wretching in our gut as the towers went down. A small voice that says, that could easily have been me, or a loved one. We have nothing comperable to attack with, you are not going to frighten someone brain washed into commiting suicide.
Where does that leave us ? They can make us afraid, but as a civilized group we have nothing comperable to hold over their heads. However, the phrase 'civilzed group' offers a glimpse into what I believe is a potential weapon. As a civilized group we are taught to punish those directly resposible against whom we are largely impotent. I would advocate instead that we scare those who assist them. A worst case scenario, destroying an orphanage above the terrorist headquarters is repugnant, but IMHO necessary. The goal is to make the next manager of the orphanage less likely to to give sanctuary. Destroy the television stations spewing hate and propaganda. Burn the banquet hall holding a fund raiser. Make the people who support the terrorists afraid, and the terrorists will have fewer places to sleep, and less to eat.
While I agree with your idea of extending the contept of the office suite beyond the stasis of MS Office I do not agree with your premise that compatibility with existing products is bad. As the maintainer of Gnumeric my goal is not to develop a research project. I want a spreadsheet that is better than what I use for my day job, MS Excel. That is going to require a huge user base and a thriving developer community. Open Source/Free Software is not a magic wand. Ten people working in their spare time are not going to instantly develop a competitor to a project that has 10 years of development and is nearly ubiquitous. First we embrace the standard, then we can extend it.
Other than graphing and frozen panes (both of which are under development for the july 1.0 freeze) I'd say that you need to look at more recent versions of gnumeric. We easily surpass Applix in many ways. If you look past feature count to feature quality Gnumeric compares fairly well to OpenCalc too. MS Excel is the target. Comparing to anything else risks being ignored for having artificially low expectations.
The problem you are describing is why Gnumeric has adopted the motto 'A close to MS Excel as necessary, but no closer'. There have been complaints that Gnumeric is replicating too much of Excel's behavior. In my opinion these people are being short sighted. Free office applications are not limited to supplying ONLY Microsoft compatible features. However, they are requried to supply a significant subset, and excellent import capabilities. A person using an office application does not want, and should not need, to waste their time converting from one application to another. Notice the huge number of '1-2-3 compatibility' features an flags in MS Excel. They made sure that a lotus user lost an absolute minimum when transitioning. The trick was that it was a one way path:-) Export filters have never been a high priority for Microsoft, for obvious reasons.
The beauty of having the source code for things like Gnumeric is that we're not locked into the feature tread mill of Microsoft. The planned 1.0 release this summer does not attempt to match every feature in MS Office. It's goal is to provide a stable sufficent platform for people to get things done. As we build market share, and gain resources, we can begin improving functionality.
We've worked very hard to have Gnumeric import workbooks from MS Excel correctly. This has meant figuring out more than I want to know about MS fonts. However, when viewing the same sheet in gnumeric and XL MS looks better. It all boils down to the fonts. Until Unix can render fonts (at odd sizes) in a nice pleasing fashion we will always look rough around the edges (pun fully intended).
Please send me a sample of an xls file with hebrew in it and I'll ensure that we can read it. Rendering should also work with appropriate fonts. Editing cell content will not work until pango.
There were once MSDN docs for XL's biff records and some of the more general escher records used in office97 for drawings. While writing Gnumeric's XL import/export facilities we have frequently run up against the limits of these documents. Even when the specs are are crystal clear (not frequent) they do not cover what the information represents. Knowing that the colour is 'index 65' (with a valid range of 8-63) is not helpful... It is certainly possible to get a fair amount of information, including pivot tables and charts, but getting it all is far from complete in Gnumeric or StarOffice.
Thanks for the vote of confidence. We do not intend to toss gnumeric and start coding on starcalc. When the SO code becomes available we'll evaluate it and start adding its capabilites to gnumeric. There are two goals.
1) Produce the best possible spreadsheet.
2) Embrace and extend MS excel so that existing sheets can migrate smoothly
Until we get access to code there is no way of knowing which code base will get there faster.
My main focus of development recently has been adding charting support. The next release will support a subset of MS excel chart types via a guppi component. Thanks to the anti-aliased canvas they already look better than XL.
We're well aware of this problem and are considering solutions. Recent development has focused on stability for the core functionality. I believe that Gnumeric is now far enough along that it use usable on a day to day basis for basic sheets. Current work is now aimed at completing the layer of features (eg graphs, autoformating). Once these changes go in we can start to address some of the performance issues. Come hell or high water the massive slow down loading sheets with lots of styles will be fixed. It is actually quite an interesting problem. Please contact me if you are interested in working on an algorithm for this.
"Gnumeric. Maybe someday it will be finished. There's more there than there used to be. Want a graph? A border on a cell? Forget it; you can't have it yet.
The current development version contains both. Borders, are almost feature complete. Graphs will be in the next release. Both have existing support for import from MS excel.
The economic argument would tend to favour using computers as extra storage for brains. rather than the converse. Something like : 'The Turing Solution' by Harry Harrison & Marvin Minsky seems less likely to bring down the wrath of the lord (or its local equivalents) than growing extra brains. I assume you aimed to grow, not purchase or procure:-)
Slashdot Mirror
I have spent a long long time trying to properly import MS Excel documents into Gnumeric. This requires reading serveral layers of formats to extract the raw data.
- ole : to get access to the files
- biff : to access the primary records
- escher : to handle embedded objects
plus other bits further up the food chain, like emf/wmf.
Reading the raw data is the least of our concerns. Understanding what it represents is quite another thing. A few years back MS tried to pull a fast one. They published some 'Developer Guides' for MS Excel (4 5 20 of some integer if they do not document how to map from the index to a colour. I'd estimate that the docs covered no more than 1/2 of the actual format.
Sticking all of the information into xml doesn't solve the problem. It just ameliorates the lower level pain. We still need to document, _clearly_ document the precise meaning of each field along with their relationships. XML makes verbosity/size and issue alot sooner than binary formats. It is easy to claim that compressed xml is about the same size as uncompressed xls, but that is not a valid comparison. Compressing the format makes it alot less useful (no random access). It is also a perfomance nightmare. In Gnumeric we've had to give alot of thought to our xml format to minimize the amount of replicated information. This makes it much faster to read, but makes it more opaque.
Even if we can magicly hurdle all of these issue there is still the fundamental point that a file format is dump of an application's state. That state includes your data, and a pinch of the application specific wrapping. Presumably your data can travel to other similar apps (not necessarily true for spreadsheet functions) but the application data is going to depend alot on how _this_ version of this application perceives things. If another app wants to read that data it needs to support a super set of the originating features, and must be able to map (quickly) to the new representation.
So, just tossing some docs into the public domain are probably not going to do much. Heck we've had docs for most of the lotus wk* formats for 2 years, but have never had time to write an importer never minds an exporter. Anyone want to help ?
Gnumeric started 3.5 years ago well before StarOffice began its transition to OpenSource. Our goal has always been to produce a the best possible spreadsheet, and we chose the GNOME project as our toolkit. I've looked at the source for kspread and attempted to borrow code from OpenCalc and have concluded that while they each have their strengths, Gnumeric's architecture feels like it is a better basis for development. Try loading large or complicated workbooks into either and compare for yourself.
The GNOME project has a well developed and evolving toolkit specificly _because_ of projects like Gnumeric, Evolution and Galeon. A toolkit without developers does not progress very quickly.
/. scooped us, and posted before I'd sent the release announcement.
While your goal is noble I think you miss an important point. People are only willing to switch to something new IF the transition is relatively painless. It is not an accident that MS Excel (tm) includes lots of old and ignored lotus-1-2-3 compatibility utilities. We can have the most fantastic spreadsheet in history, and it would still be largely ignored unless there is an easy way to convert XL files to/from Gnumeric. Which is pretty much the plan. Once we have a spreadsheet that can interact well enough with XL people can extend it to add all the lovely innovations they can think of. Remember the MS mantra 'Embrace, Extend, ...'
Several of the core Gnumeric developers use it for real work, and based on our bug reports so do many other people. Most of us are working on the project because we are so familiar with the pain and the power of MS Excel (tm). When it works it is a hugely powerful piece of work, but when it doesn't you are up a creek. The 1.0 version of Gnumeric will not replace MS Excel (tm) for a power user. However, it should be sufficient for most day to day users. The goal is to produce a platform that will be able to do all the things we're used to, and hopefully we're on the right track.
The release notes would be useful.
I don't know what version you tried but we should be damn near pixel perfect for borders, patterns, formats, content and values. Sheet objects like buttons and drawings still need work.
IMO people who discuss 'Retaliation' and 'Measured responses' miss the point. The former is nothing more than a polite phrase for Revenge, and the latter is ineffective. Terrorists have moved the playing field away from the civilized world's strength, military power, and moved it into it an area of weakness, fear. As a weapon fear is currently a very one sided arsenal. We all felt a wretching in our gut as the towers went down. A small voice that says, that could easily have been me, or a loved one. We have nothing comperable to attack with, you are not going to frighten someone brain washed into commiting suicide.
Where does that leave us ? They can make us afraid, but as a civilized group we have nothing comperable to hold over their heads. However, the phrase 'civilzed group' offers a glimpse into what I believe is a potential weapon. As a civilized group we are taught to punish those directly resposible against whom we are largely impotent. I would advocate instead that we scare those who assist them. A worst case scenario, destroying an orphanage above the terrorist headquarters is repugnant, but IMHO necessary. The goal is to make the next manager of the orphanage less likely to to give sanctuary. Destroy the television stations spewing hate and propaganda. Burn the banquet hall holding a fund raiser. Make the people who support the terrorists afraid, and the terrorists will have fewer places to sleep, and less to eat.
It's not 'civilized' but it may be effective.
While I agree with your idea of extending the contept of the office suite beyond the stasis of MS Office I do not agree with your premise that compatibility with existing products is bad. As the maintainer of Gnumeric my goal is not to develop a research project. I want a spreadsheet that is better than what I use for my day job, MS Excel. That is going to require a huge user base and a thriving developer community. Open Source/Free Software is not a magic wand. Ten people working in their spare time are not going to instantly develop a competitor to a project that has 10 years of development and is nearly ubiquitous. First we embrace the standard, then we can extend it.
Other than graphing and frozen panes (both of which are under development for the july 1.0 freeze) I'd say that you need to look at more recent versions of gnumeric. We easily surpass Applix in many ways. If you look past feature count to feature quality Gnumeric compares fairly well to OpenCalc too. MS Excel is the target. Comparing to anything else risks being ignored for having artificially low expectations.
The beauty of having the source code for things like Gnumeric is that we're not locked into the feature tread mill of Microsoft. The planned 1.0 release this summer does not attempt to match every feature in MS Office. It's goal is to provide a stable sufficent platform for people to get things done. As we build market share, and gain resources, we can begin improving functionality.
Embrace, Extend, ...
I've got to disagree with you.
We've worked very hard to have Gnumeric import workbooks from MS Excel correctly. This has meant figuring out more than I want to know about MS fonts. However, when viewing the same sheet in gnumeric and XL MS looks better. It all boils down to the fonts. Until Unix can render fonts (at odd sizes) in a nice pleasing fashion we will always look rough around the edges (pun fully intended).
Please send me a sample of an xls file with hebrew in it and I'll ensure that we can read it. Rendering should also work with appropriate fonts. Editing cell content will not work until pango.
There were once MSDN docs for XL's biff records and some of the more general escher records used in office97 for drawings. While writing Gnumeric's XL import/export facilities we have frequently run up against the limits of these documents. Even when the specs are are crystal clear (not frequent) they do not cover what the information represents. Knowing that the colour is 'index 65' (with a valid range of 8-63) is not helpful... It is certainly possible to get a fair amount of information, including pivot tables and charts, but getting it all is far from complete in Gnumeric or StarOffice.
Thanks for the vote of confidence. We do not intend to toss gnumeric and start coding on starcalc. When the SO code becomes available we'll evaluate it and start adding its capabilites to gnumeric. There are two goals.
1) Produce the best possible spreadsheet.
2) Embrace and extend MS excel so that existing sheets can migrate smoothly
Until we get access to code there is no way of knowing which code base will get there faster.
My main focus of development recently has been adding charting support. The next release will support a subset of MS excel chart types via a guppi component. Thanks to the anti-aliased canvas they already look better than XL.
We're well aware of this problem and are considering solutions. Recent development has focused on stability for the core functionality. I believe that Gnumeric is now far enough along that it use usable on a day to day basis for basic sheets. Current work is now aimed at completing the layer of features (eg graphs, autoformating). Once these changes go in we can start to address some of the performance issues.
Come hell or high water the massive slow down loading sheets with lots of styles will be fixed. It is actually quite an interesting problem. Please contact me if you are interested in working on an algorithm for this.
"Gnumeric. Maybe someday it will be finished. There's more there than there used to be. Want a graph? A border on a cell? Forget it; you can't have it yet.
The current development version contains both.
Borders, are almost feature complete.
Graphs will be in the next release. Both have existing support for import from MS excel.
Please try a newer version.
The economic argument would tend to favour using computers as extra storage for brains. rather than the converse. Something like : :-)
'The Turing Solution' by Harry Harrison & Marvin Minsky
seems less likely to bring down the wrath of the lord (or its local equivalents) than growing extra brains. I assume you aimed to grow, not purchase or procure