OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

opendocument-users message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


Hi Stefan,

On Fri, May 12, 2006 at 15:53:33 +0200, Stefan Nikolaus wrote:

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

I don't think so, but I may be wrong. Let's clarify:

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


> > 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. As all misunderstanding shows, that paragraph needs to be
rephrased.


> > > 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. If cells need attribution even if empty,
they should be written as empty cells.


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

  Eike


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]