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

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

Hello everybody,

On Thursday 11 May 2006 15:13, Eike Rathke wrote:
> On Mon, May 08, 2006 at 14:38:11 +0200, Stefan Nikolaus wrote:
> >   <row default-cell-style-name="ce1">
> >   <cell>1</cell>
> >   <cell/>
> >   </row>
> >
> > OpenDocument specification, ch. 8.1:
> > "Incomplete rows are basically rendered as if they had the necessary
> > number of empty cells,"
>
> In both cases there are no empty cells.

There is an empty cell for the 1x1 doc, because a for a 2x2 spreadsheet app a
default row would be of 2x1 dimension. So, the first row is incomplete in that 
sense.

As for the 'just like in an empty sheet' I have to go further into details.
I cite the third paragraph of 8.1 here, so we have it all at once (I made some 
pseudo paragraphs for better readability):

| Table rows may be empty, and different rows might contain a different number
| of table cells. This is not an error, but applications might resolve this 
| in different ways. 
| 
| Spreadsheet applications typically operate on large tables that have a fixed
| application dependent row and column number, but may have an unused area.
| Only the used area of the table is saved in files. 
|
| When loading a table with empty or incomplete rows into a spreadsheet
| application, empty rows typically introduce a default row (just as in an
| empty sheet), and incomplete rows are filled with empty cells (just like in
| an empty sheet).   
|
| All other applications typically have fixed size tables.
|
| Incomplete rows are basically rendered as if they had the necessary number
| of empty cells, and the same applies to empty rows. Empty cells typically
| occupy the space of an empty paragraph.

I'm wondering wether the two last pseudo paragraphs belong together. Maybe - 
if one regards the space hint (without structuring paragraphs this is 
confusing; also the 'typically').

If this is the case my two example documents would be rendered the same in 
non-spreadsheet apps only. This implies for me that the @dcsn applies to the 
whole row in those, but not in spreadsheet apps. Taking the first pseudo 
paragraph into account this would not be an error. The spreadsheet app 
loading paragraph stands on its own, the rendering is not described 
explicitly for spreadsheet apps and Eike's interpretation would be right.

Me bothers, that with this interpretation different looking tables would be 
created in different apps (think copy&paste). A worst example would be a 3x3 
doc, which assigns @dcsn to each column. Let's say a black background. Further 
all three cells in row three have content, the first two row remain empty. In 
a spreadsheet app we got only row three as black. In other apps the whole 3x3 
table is black.
IMO, this can't be the intention.


If the two last pseudo paragraphs have to be considered separately, the things 
makes more sense to me:
The rendering pseudo paragraph would also hold true for spreadsheet apps.
The term 'just as in an empty sheet' just refer to the amount of cells. These 
cells are empty and have no assigned style. Even if they are empty, they 
belong to a row and a column. So, they have to use the @dcsn as it is 
specified.
For saving: The @dcsn belongs to the row or column and is not considered for 
the determination of the used area. Empty cells are ones without content and 
without an assigned style.
This results in table representations, where the used area look the same in 
_all_ apps.


Robert stated the brevity as reason. This makes parsing and writing out 
faster. The storage gain would minimal due to compression. So, applying @dcsn 
to the used area only could make sense. But as I've explained above, this 
leads to different interpretations of the same table representation for 
different apps. Also it introduces the already mentiioned exception. 
Conclusion: A no go for me.

Regards,
Stefan

PGP signature