[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [opendocument-users] Re: How to interpret the default-cell-style-name attribute in spreadsheets
Hi Stefan, I haven't been following the discussion closely until now, but I have re-read the entire conversation and I don't agree that a consensus was reached on your stated conclusion. What I read into the discussion is that the specification is vague on this matter, and that OpenOffice.org's current behaviour is what the specification was trying to describe. To support my view, I think I have found where the idea of @dcsn comes from (this is a Gnumeric mailing list posting from 6 years ago, some of the correspondants now work on OO.org): http://mail.gnome.org/archives/gnumeric-list/1999-July/msg00022.html The source code for Gnumeric ODS import filter contains some helpful notes on this as well. From a practical point of view, interpreting @dcsn as applying to the whole row / column just isn't very useful, and @dcsn is only there for pragmatic reasons. Regarding the usage of tables in spreadsheets and tables in other applications, unless I am missing something, I don't think there is an inconsistancy because there is a crucial difference between the two types of applications. In a word processor or presentation, the table has a clearly defined size (ie. however many rows or columns it has when you create it). In a spreadsheet, the table does not have a 'size' - since a spreadsheet is basically an infinite table. In order for @dcsn to be useful, you have to pretend that the table does only have a certain size, and the easiest way to do this is to take the number of columns and rows in the used area. My understanding of @dcsn is that if we have a spreadsheet whoose right-most column containing a non-empty cell is say column G and whoose bottom-most row containing a non-empty cell is row 100, then default cell styles will apply from cells A1 to G100 when loading the spreadsheet in, and not outside of that range. That is if I were to specify a default cell style for column G it would apply to G1-G100. If I were to specify a default cell style for row 100, it would apply to cells A100-G100 In other words, it will act like a fixed 100x7 table in a word document or presentation. Regards, Robert. On 06/06/06, Stefan Nikolaus <stefan.nikolaus@kdemail.net> wrote: > Hello all, > > it seems, the discussion came to an end. Let me summarize my observations: > > 1. There's nothing explicitly mentioned in the current spec, which says that > the @dcsn should be used for the used area only. > 2. The only interpretation, that allows the @dcsn to be applied to the used > area, results in different interpretations for spreadsheet and other apps. > 3. Applying the @dcsn to the used area only would mean an exception as all > other column/row attributes apply to the whole column/row. > > Conclusion: > The @dcsn should be applied to the whole column/row. > > Proposals: > 1. Split the third paragraph of 8.1 "Basic Table Model", so it becomes more > obvious, that the rendering part belongs to both kind of apps. It would also > increase the readability. > 2. Clarify, that the spreadsheet loading part refers to the dimension of the > spreadsheet app, not the dimension of the saved doc. It's already given > by 'just like in an empty sheet', but obviously it's not definite enough. > > The rest seems for me well-defined. Seriously, my respect to the guys > involved. Even more, if they all were working on the same spreadsheet app > (OO.o Calc) as it was stated. Specifications/Definitions don't belong to the > trivial parts of development. > > Hats off, > Stefan > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]