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
> or cc me directly in case of a relevant response. Thank you.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
>
