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