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

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

Hi Eike,

On Friday 09 June 2006 16:01, Eike Rathke wrote:
> On Fri, May 19, 2006 at 18:31:30 +0200, Stefan Nikolaus wrote:
> > > 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?
>
> These _are_ the application's empty cells. If you create a new sheet in
> your application, its cells are rendered as empty somehow. The same with
> the unused area that is not covered by a table loaded from the document.

For which the @dcsn have to be used, if there are any, as defined in the 
rendering paragraph.

> > And where would be the difference to other applications?
>
> The difference is that other applications usually do not have an unused
> area in terms of cell ranges. For them, the table and the used area are
> identical

Okay. There would be no difference with respect to the loading between both 
kind of apps for the case, if 'just like in an empty sheet' would refer to 
the doc's dimensions. But you already said, that it's the application 
dimension.

> > 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.
>
> Not in this case.

Okay, partly true. For the spreadsheet app the used area would be reduced to 
3x2 after loading.

> But what if columns D..ZZZ and rows 4..999 are  
> intended to not be rendered 'g' respectively 'r', like shown in my
> example. What would you store if you didn't want your app render it like
> in your spreadsheet apps table?

<table:row>
<table:cell style-name="r" columns-repeated="3"/>
</table:row>
<table:row>
<table:cell style-name="g" columns-repeated="3"/>
</table:row>
<table:row>
<table:cell style-name="r" columns-repeated="3"/>
</table:row>

> > 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.
>
> Which would mean you'd have to store attributes for every cell instead?
> That's counterproductive.

It's what the spec says.

> > My worst case example for the case in which the last two pseudo
> > paragraphs belong together (as those ASCII tables are so nice ;-) )
>
> Just that you seem to try to draw alignments using some proportional
> font, which obviously doesn't work.. ;)

Obviously. :-)

> > 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	|
>
> I didn't get that. Or is it about totally empty rows, not even empty
> cell elements stored?

Yes, that would be the result for the case, if the rendering paragraph would 
not apply to spreadsheet apps.

> > The difference is IMO not tolerable.
>
> IMHO the other apps shouldn't draw 'b' attributes then.

So, the rendering paragraph has to take effect for both kind of apps, which in 
turn implies that the @dcsn has to be applied to the whole rows/colums.

Bye,
Stefan

PGP signature