OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [sc-dev] Re: Data Grid Size element proposal

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.]



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 office-comment@lists.oasis-open.org 
> or cc me directly in case of a relevant response. Thank you.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@sc.openoffice.org
> For additional commands, e-mail: dev-help@sc.openoffice.org

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]