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