Re: More than 64K Rows (and misc comments)
- From: Jody Goldberg <jody gnome org>
- To: Floris Kraak <floris snow nl>
- Cc: gnumeric-list gnome org
- Subject: Re: More than 64K Rows (and misc comments)
- Date: Mon, 7 Oct 2002 12:30:06 -0400
On Mon, Oct 07, 2002 at 05:46:13PM +0200, Floris Kraak wrote:
On Sun, Oct 06, 2002 at 12:37:49PM -0400, Jody Goldberg wrote:
On Sun, Oct 06, 2002 at 10:46:04AM -0400, FRANCISCO CUENCA ACUNA wrote:
PS: Why don't you ship Gnumeric with 128K rows by default? This would be a
good selling point against excel. In fact it is the reason why I'm
evaluating currently gnumeric.
At some point we may, as things stand it is useful for compatibility
reasons to be the same as MS Excel.
Compatibility reasons? What compatibility reasons are those,
exactly? The only one I can think of would be saving large gnumeric
sheets in excel format, and in that case I'd say putting in an error
message when 'save as excel' is used should catch that problem.
Maybe I'm wrong, but I feel GNOME should not be responsible for
perpetuatating Microsoft design errors.
The main reason is that XL has the nifty (not!) property that it
does not bother to do bounds checking, and people actually depend on
this. So setting up a named expression to reference 1 cell to the
left of the current will happilly work in the left most column by
wrapping around to the last column. I'm not too worried about
warning that data will be truncated from big gnumeric -> small XL.
We already have to do that when exporting to XL95 (16k rows).
But the potential for silently changing the behavior of a
spreadsheet gave me some pause. Not a huge amount, but enough that
I did not want to just leap in and make the change unilaterally.
There are a few such changes to consider in the coming days as I
start tuning the parser after all the recent changes for applix and
opencalc.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]