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 the default-cell-style-name attribute in spreadsheets


Hi Stefan,

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.

> 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 

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

I'm not sure whether that holds true for all applications. There might
be cases where a wordprocessor could do different and render cell
borders individually, for example. I didn't dive into that.


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

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

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

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

> The difference is IMO not tolerable.

IMHO the other apps shouldn't draw 'b' attributes then.

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

Applying @dcsn to the used area only was our intention, so it seems
we'll have to clarify that in the spec.

  Eike


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