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

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

Hi Eike,

On Thursday 18 May 2006 17:32, Eike Rathke wrote:
> On Fri, May 12, 2006 at 15:53:33 +0200, Stefan Nikolaus wrote:
[...]
> > > > | 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).
> >
> > If you have an empty row (empty row means, following the spec, even no
> > empty cells), a default row is introduced 'just like in an empty sheet'.
> > For the 2x2 app an empty sheet's default row has the dimension 2x1. So,
> > this and the handling of incomplete rows refer to the application
> > dimension. I.e. a row is incomplete for this app, if it has less than 2
> > columns.
>
> A table stored in a document has a certain dimension, which was the used
> area in the application it originated from. If the table stored in
> a document has the dimension 1x1, then there are no empty cells and no
> empty rows and no incomplete rows, no matter which size the sheet of the
> application loading it may have. The empty cells you are referring are
> the application's empty cells it renders because of its sheet size, they
> are not part of the table stored in the document.

Where takes the 'just like in an empty sheet' place in this interpretation?
And where would be the difference to other applications? The paragraph 
describes explicitly the loading behaviour of spreadsheet apps. If there 
would be no difference the whole paragraph would be superfluous. As the 
behaviour you have described holds also true for other apps this would be the 
case. See below...

> > > Since it says "all other applications" after spreadsheets were treated,
> > > and talks about features a spreadsheet doesn't have (cells occupying
> > > the space of an empty paragraph), I'd say the entire "basically
> > > rendered" doesn't apply to spreadsheets at all. The wording should make
> > > that more clear.
> >
> > Well, even spreadsheets have paragraphs: The cell content is described by
> > <text:p> elements. As this 'typically' steps in, one could say, that it
> > refers to the cells of a default row. So, if you have no default style
> > for row elements, the height of an empty paragraph could be used.
>
> This may be valid for a row element. However, as that "Empty cells
> typically occupy the space of an empty paragraph" follows the
> description of empty rows _and_ incomplete rows of _other_ applications,
> it is misleading for spreadsheet applications. In a spreadsheet
> application you "typically" don't render cells individually at different
> heights.

.. just as in other apps. You _generally_ don't render cells belonging to the 
same row with different heights. As I already stated: if the row height is 
undefined, you use the height of an empty paragraph. This can hold true for 
both kind of apps. Wether these two pseudo paragraphs belong together is 
still not clear, if we just look at this. Therefore, I tried to elaborate the 
two possibilities in my last mail.

> As all misunderstanding shows, that paragraph needs to be 
> rephrased.

Indeed.


The conclusion of possibility 1 (the last two pseudo paragraphs belong 
together):
> > > > 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.
> > >
> > > Not if the first two rows contain <table:table-cell> elements. Or to be
> > > more precise, for optimization they should be represented by something
> > > like
> > >
> > >   <table:table-row table:number-rows-repeated="2">
> > >     <table:table-cell table:number-columns-repeated="3"/>
> > >   </table:table-row>
>
> > Right, but I was speaking about empty rows and had the spec definition of
> > this in mind: even no empty cells (Empty as in: <table:row/>).
> >
> > To clarify this example: The @dcsn should be applied to the first three
> > columns and the first three cells of row three should have content.
>
> I know what you're referring, but this behavior was not the intention,
> at least not from a spreadsheet's view.
>
> > > If the cell elements are not present or not repeated with the proper
> > > count then yes, the background wouldn't be rendered for the remaining
> > > "empty cells like in an empty sheet".
> >
> > Nothing to say about the different interpretations of the same table
> > representation in different apps? I'd like to hear yor opinion about
> > this.
>
> I don't know what the intention was to define the processing different
> for other applications, nor am I sure that the intention was to define
> it different or if that was a misunderstanding instead. Maybe someone
> from the word processor team could clarify. IMHO the behavior should not
> had been defined different.

Agreed as I don't see any reason why this should be the case. It would be 
confusing.

> If cells need attribution even if empty, 
> they should be written as empty cells.

So much for brevity. ;-)

If you interpret them the above way, i.e. the last two pseudo paragraphs are 
defined just for other apps, there would be no difference regarding the 
loading of empty cells between spreadsheet and other apps. And this would 
make the explicit spreadsheet loading behaviour paragraph superfluous.

Table definitions are not handled different, if the last two pseudo paragraphs 
don't belong together, i.e. the rendering has to be considered also for 
spreadsheet apps.


Possibility 2 (the last two pseudo paragraphs are treated separately):
> > > > 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.
> > >
> > > This makes no sense. You would have to store artificial @dcsn for the
> > > unused area then to represent the spreadsheet application's default
> > > empty sheet rendering.
> >
> > Pardon? I have to do what?
> > (Step back from your @dcsn applies to the used area in this case.)
>
> Now I'm lost. I thought we were talking about empty cells not part of
> the document, and the unused area where you said that the remaining
> cells were part of an incomplete row.

Right. You said, that it's necessary to introduce artifical @dcsn. It is not, 
if you apply the @dcsn to whole columns/rows. It may look different as you 
expect, but it is not necessary.
As I've already stated in my last mail, the @dcsn would belong to the 
row/column (as one actually expects).

> Let's do a simple example, a 3x3 
> table stored in the document, with @dcsn=red for all columns, and
> @dcsn=green for row2, no empty cells and no incomplete rows, loaded in
> a 4x4 application:
>
>  +---------------------------+
>
>  |   |  A  |  B  |  C  |  D  |
>  |
>  |---+-----+-----+-----+-----+
>  | 1 |  r  |  r  |  r  |     |
>  |---+-----+-----+-----+-----+
>  | 2 |  g  |  g  |  g  |     |
>  |---+-----+-----+-----+-----+
>  | 3 |  r  |  r  |  r  |     |
>  |---+-----+-----+-----+-----+
>  | 4 |     |     |     |     |
>
>  +---+-----+-----+-----+-----+
>
> How would you render column D and row 4 in this case?

Spreadsheet apps:
|	|  A	|  B	|  C	|  D	|
|  1	|  r	|  r	|  r	|  	|
|  2	|  g	|  g	|  g	|  g	|
|  3   |  r	|  r	|  r 	|	|
|  4	|  r	|  r	|  r 	|	|
Other apps:
|	|  A	|  B	|  C	|
|  1	|  r	|  r	|  r	|
|  2	|  g	|  g	|  g	|
|  3   |  r	|  r	|  r 	|
The basic table (used area: 3x3) is the same in both kind of apps. No need to 
define artifical @dcsn for col D and row 4. The @dcsn works as expected, it 
is applied to the whole column and row. If you want the style not to take 
effect for the inserted empty cells, don't define @dcsn.


My worst case example for the case in which the last two pseudo paragraphs 
belong together (as those ASCII tables are so nice ;-) ) and your 
interpretation would be right:
Spreadsheet apps:
|	|  A	|  B	|  C	|  D	|
|  1	|	|	|	|	|
|  2	|	|	|	|	|
|  3   |  b	|  b	|  b 	|	|
|  4	|	|	| 	|	|
Other apps:
|	|  A	|  B	|  C	|
|  1	|  b	|  b	|  b	|
|  2	|  b	|  b	|  b	|
|  3   |  b	|  b	|  b	|
The difference is IMO not tolerable.

My conclusion of this is, that the spec can't be interpreted in a way which 
applies the @dcsn to the used area only.

Regards,
Stefan