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 12 May 2006 14:25, Eike Rathke wrote:
> On Fri, May 12, 2006 at 11:13:23 +0200, Stefan Nikolaus wrote:
> > > 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.
>
> This is exactly the misunderstanding. There is no empty cell in the
> table stored in the document, the row is not inclomplete. The
> application renders more cells than there are in the document. The @dcsn
> does not apply to those cells. Instead, those cells should be rendered
> like cells in an empty sheet.

Sorry, no, you misunderstand this:
> > | 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.

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

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

> 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.
From my point of view, the first pseudo paragraph, which speaks of different 
handling of incomplete and empty rows, refers just to the fact, that 
spreadsheet apps 'insert' additional rows/cols and other apps don't. The 
basic table (the used area) should remain the same and should not look 
different, if you use the same table definition.

> > 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.)
Are you refering to my worst case example? It looks in this interpretation as 
follows: In a spreadsheet app the whole first three columns are black. In 
other apps a 3x3 table is rendered, which is completely black.

> And to which columns should they apply? There are no more
> columns/rows in the document than the used area that is stored as table.

The filled in empty cells apply to the columns 'inserted' by the spreadsheet 
app, which are default ones for the unused area. The default columns 
generally have no @dcsn.

Regards,
Stefan

PGP signature