I just forgot this:
Does implementing a MAX_GRID_SIZE also mean, that none of OOo, gnumeric
or another existing ODF-compliant application will be able to READ files
saved with the latest Excel?
[As far as I know, none of these support the grid-limits of Excel, even
gnumeric needs a specific recompile.]
Sincerely,
Leonard
Leonard Mada wrote:
Dear TC Members,
while reading the discussion, I have to express my dismay to the
proposal and more broadly to the various spreadsheet concepts. It
seems little has been learned from past mistakes.
Warren Turkal wrote:
[...]
This doesn't seem useful to me. If I never address anything in those
cells that are outside my range, I'd say it's pretty likely I don't
care about them, and just knowing the max row/col size of the saving
application doesn't tell you that.
[see http://lists.oasis-open.org/archives/office/200811/msg00138.html]
I must strongly back up Warren on this one.
Lets say it this way: suppose I have a spreadsheet program WITHOUT any
grid-size limit (because it implements a very clever iterative
mechanism - making it virtually infinitely wide). I create a 2 columns
by 2 rows spreadsheet. BUT this one is virtually non-openable in any
other program! So, basically THIS spreadsheet program, WHILE FULLY
ODF-CONFORMANT, does create spreadsheets that are NOT READABLE by ANY
other application. So, why the fuss with ODF than?
This is BAD standard design, depending on an implementation detail.
Lets move further. Putting the constraints on the application is
definitely wrong. Even if an application supports 1E+30 rows, it is
still MOST likely that 90% of users will use less than 10,000 rows,
and that 99% of them will use less than 30,000 rows. So, WHY put a
MAX_GRID_SIZE at 1E+30 then?
A different measure is useful! And Apple solved this nicely in Numbers.
What is needed is the ACTUAL size of the current spreadsheet. If there
are only 2 rows by 2 columns, than THIS is needed. If the user adds
more rows/columns, than the spreadsheet program shall automatically
increment as necessary (this is a nice feature in Numbers). We don't
have any problems with named ranges and general <row>/<column>
references anymore. WE have now a portable value - and a clearly
defined one.
Referencing a value outside this range shall generate an error and NOT
silently accept 0, if it falls within the MAX_GRID_SIZE. This is
currently a design error. I have yet to see such a use that is not an
error, and I have enough auditing experience to say this. If the user
really needs this (which I really doubt), he will notice the error and
explicitly write something on the corresponding row or column (to
define that row or column, e.g. a label). This is much more
transparent and error-proof.
Eike wrote:
see http://lists.oasis-open.org/archives/office/200811/msg00155.html
Now if this file was loaded in an application that supported more
columns without knowing the original maximum grid size, the formula in
A2 would yield 0 because the range wrapped pointing to then empty cells.
What applications actually can or should do about this is beyond the
scope of the file format standard, nevertheless it seems to be a good
idea to include the hint of the original grid size.
This is again wrong logic. The application does NOT want to know the
MAX_GRID_SIZE, BUT the *actual spreadsheet size*!
So IF the TC is clever it will follow Apple's approach, and limit the
spreadsheet size to its actual size, and not limit the application.
[By the way, I consider Numbers much better than all other
spreadsheets combined, and I feel Apple is brewing even more things.]
Sincerely,
Leonard
P.S. Please move the discussion to [EMAIL PROTECTED]
or cc me directly in case of a relevant response. Thank you.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
