GNOME Bugzilla – Bug 353004
remove the 256 columns limit
Last modified: 2008-04-25 17:15:13 UTC
Wikipedia mentions that "Other popular spreadsheet programs are limited to 256 columns". ( http://en.wikipedia.org/wiki/Gnumeric ) I wish the default, out-of-the-box Gnumeric could handle much more. Then we could have a quick answer when people ask "Why is Gnumeric better than other spreadsheets?". Also, we could fix that lame-sounding FAQ entry into something that sounds much more impressive. Some possibilities: * Perhaps make the default, out-of-the-box limit "ZZ", giving 26*26 = 676 columns ? ( http://gnome.org/projects/gnumeric/faq.shtml#5 implies this is easy to do ) * Keep the 256 column limit, but import and export unlimited-width CSV files as a series of "sheets" * limited to just under MAX_UINT ? * no limit at all -- "limited only by RAM" ? Is there any usability reason to hard-code some limit? (I hope this isn't a dupe of Bug 50881 )
This is definitely a bug. I just spent time today explaining to a support person at the Internet Archive that their problems with exporting data in CSV files that would crash Excel because of some crazy 65,000 row limit would be eliminated if they moved to a GNU spreadsheet, because the GNU Coding Standards require that the program not have fixed, compiled-in limits. And further explained that the bug would be taken seriously by the developers, if such a limit was found and reported by her. (I was asking them to export a million-line web crawl log as a CSV file so that recipients could easily sort and select it and do other spreadsheety things with it.) Then I came home and looked -- and Gnumeric has hard-coded limits on both rows and columns (65536 and 256 respectively). And that when this was reported as a bug in 2001, the developers closed it out without fixing it, by doing a circumvention that barely worked for the one single case reported (Bug 50881). I was shamed to have depended on my community to "do the right thing". http://www.gnome.org/projects/gnumeric/faq.shtml#5 says that gnumeric supports larger rows and columns "with a recompile" -- but it even includes a caveat about how slow the resulting program will be. That doesn't meet the coding standards!
*** Bug 524575 has been marked as a duplicate of this bug. ***
I'm working on a quad tree based mechanism for the cells akin to the way we store styles. However, it is going to require some significant retooling.
*** This bug has been marked as a duplicate of 168875 ***