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

 


Help: OASIS Mailing Lists Help | MarkMail Help

opendocument-users message

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