Fwd: Re: [office] Re: Feedback on Comment list

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

Keeping it semi-public.

----------  Forwarded Message  ----------

Subject: Re: [office] Re: Feedback on Comment list
Date: Thursday 07 September 2006 16:23
From: Stefan Nikolaus <stefan.nikolaus@kdemail.net>
To: Michael Brauer - Sun Germany - ham02 - Hamburg <Michael.Brauer@sun.com>

Hello Michael,

On Thursday 07 September 2006 14:46, you wrote:
[...]

> Did you see my clarification proposal at
>
> http://lists.oasis-open.org/archives/office/200609/msg00023.html
>
> It actually states that the attribute is not applied to cell that has no
> <table-cell> element.

Oh, sorry, I read it yesterday, but today I was somehow focussed on this
thread only.

> > this is the actual reason for the confusion. It is/was never stated
> > anywhere, that there's a difference between those and the cells
> > 'inserted' into the column/row to fill the column/row to the spreadsheet
> > dimension. Even worse
>
> I'm confused. There is no difference between these two types of cells. Why
> do you think there is one?

No, there's none. Without the restriction to cells with a <table-cell>
element, this equality is the reason of my interpretation.

> >>If any application wishes to extend the area to which a certin cell
> >>style is applied, it can easily do so by storing the required amount of
> >>cells in the document,
> >
> > As the dimensions of spreadsheet apps differ, this is not true.
> > Example: You have 2x2 app and assign bold font to the first column. If
> > you stay with the app everything is fine, but if you open the doc in an
> > 4x4 app, the bold font is just applied to the first two cells, while you
> > expect it to format the whole column. So, the storing of an specific
> > amount of cells is not adequate to represent a column/row formatting.
>
> Well, the addional cells don't contain text, so it does not make any
> difference whether there is a bold attribute or not. And since it makes no
> difference, the application in this case really is free to choose whatever
> bold attribute value it thinks is approriate. And even if the "Bold" would
> have an effect. If I save a 2x2 file in 2x2 application, and open it in an
> 4x4 application, I really don't know whether the user intended to format
> the additional cells in bold or not. I only do know what was intended for
> the 2x2 cells.

Okay, bad example, replace it with the most obvious one, the cell background.

Typically, you have thousands of rows in spreadsheet apps and the user
 selects alls cells in a column by clicking on the column header. As the user
 does not select the cells explicitly, but choses the column, the intention
 is to format all cells in the column.
But you're right, this is questionable, especially at lower sheet dimensions,
but also on the usual high ones as implementations (at least KSpread's) don't
distinguish between those explicit selections of all column cells and the
selection by column header. But I still tend to interpret it as
all-cells-in-this-column-formattings as the explicit selection of all cells
of a column is really uncommon in my experience.

> >>or, even better, it may use a row or column style.
> >
> > Now, I'm confused. Column/row styles do not specify any cell formattings
> > except the @dcsn. And, IMHO, they even should not in future versions.
>
> The @dcsn attribute is not part of column or row attribute. It's a separate
> attribute. And currently, a cell style may already contain paragraph and
> text attributes, so it would not be the first time that a certain style may
> specify properties of something that is embedded in the element to which
> style is applied. But we of course should analyze the situation in more
> depth before we add something to the ODF 1.2 spec.

In this case, these attributes apply to the cell content or the rendering of
 a cell, so I plead for keeping these as cell style attributes. Also, I
 assume, that the chance to reuse these styles is higher then.

[...]

> > I want a complete cell style, with all its formatting attributes, applied
> > to a whole column/row (app dimension). And the spec in its current
> > version allows
>
> I see. What is not clear to me is why it is not an option to store the
> table with app dimensions. For those cells that your app does not support
> but that some other apps support, you don't know whether it is right or
> wrong to apply the @dcsn attribute to it.
>
> BTW: Would it be an option if the table itself or spreadsheet elemnt would
> have a default style that is applied to all cells, including those that
> don't have a cell element?

I don't think so, we already have a default cell style for the document. I
 see no need to make this sheet dependent (I think specific formatted
 (coloured) sheets are not that common/desirable).

My intention is driven by my interpretation of the selection of all cells in
 a specific column as I described above. Additionally, it's obviously
 influenced by KSpread's current implementation of those styles and its old
 file format. :-|

Regards,
Stefan

-------------------------------------------------------

PGP signature