Re: [opendocument-users] Re: How to interpret the default-cell-style-name attribute in spreadsheets

[Stefan Nikolaus <stefan.nikolaus@kdemail.net>]

Hi Robert,

On Tuesday 06 June 2006 13:13, Robert Knight wrote:
> 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.

I wrote about _my_ observations. The conclusion and the proposals represent 
also my point of view. Should have made this clearer. :-| Sorry.

> What I read into the discussion is that the specification is vague on
> this matter,

IMO no.

> and that OpenOffice.org's current behaviour is what the 
> specification was trying to describe.

IMO no.

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

I have not read it yet. Will do later...

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

If you want "row/column styles" (a default cell style for whole rows/columns), 
it results in processing the style one time for a row/col instead of 
processing it N times (where N is usually much bigger than the amount of 
cells in one direction of the used area) when using the repetition attribute 
of cells for this. So, it's all about brevity (just the other way 
around ;-) ) and it is very pragmatic for this case. Besides that, it's more 
intuitive: for devs there's no exception; for users there's no difference 
between different spreadsheet applications (e.g. a _complete_ row has black 
background in all apps regardless of each app's dimension).

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

Right, "applications might resolve [the handling of incomplete/empty 
cols/rows] in different ways".
Interpreting the spec this way results in a different meaning of @dcsn in 
spreadsheet and in other apps, which would be just another exception a 
developer must be aware of and leads to issues with copy&pasting between 
those apps. I don't believe, that different looking used areas are meant when 
speaking of these different solutions. It's more likely the amount of cells 
inserted.

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

Right, they "have fixed size tables" (doc's table dimension).

> In a spreadsheet, the table does not have a 
> 'size' - since a spreadsheet is basically an infinite table.

Let's stay with "a fixed application dependent row and column number" to avoid 
a discussion about wether infinity is fixed or not. ;-)

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

I tried to interpret the current spec in this way. I've already stated my 
conclusion of this.

Bye,
Stefan

PGP signature