Re: [office] Re: Feedback on Comment list

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

Hi Michael, hi all,

On Wednesday 06 September 2006 16:02, Michael Brauer wrote:
> Stefan,
>
> thank you very much for your feedback. Some comments are inline.
>
> Stefan Nikolaus wrote:
> > On Monday 04 September 2006 20:58, Michael Brauer wrote:
> >>Tables: default-cell-style-name interpretation
> >
> > The @dcsn is a column/row attribute. In spreadsheet applications these
> > are also used to render the cells outside the used area - think cell
> > dimension or visibility. The @dcsn should be treated the same way.
>
> The intended purpose of the default cell style attributes is to provide
> a shorter way to specify cell style names than adding a cell-style-name
> attribute to each <table-cell> element. So, the assumption is that an
> application evaluates these attributes when it loads a <table-cell>
> element that does not has a "style-name" attribute. It therefore is
> never evaluated for a cell that does not have a corresponding
> "table-cell" element in the document. If an application displays cells
> that are not included in the document itself, it may choose whatever
> defaults it considers to be reasonable. Typically, spreadsheets
> applications use the application's default cell style.

Okay, but with the exceptions of incomplete or emtpy rows, in which the @dcsn 
is assigned to the 'inserted' cells. These have no <table-cell> elements. And 
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 
the paragraph in 8.1 speaks of 'just as in an empty sheet' with respect to 
the insertion of cells, which to means to me, that the spec refers to the 
application dimension.

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

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

> In contrast to this, if the default-style-name attributes would 
> be applied to cells that are not contained in the document, too, then it
> would not be usable any longer in all those cases where only the cells
> in the document should get the style, but not those whose who are
> displayed in addition.

Right, therefore the proposed new cell attributes. These should span an area 
of cells (like the matrix attributes), they should be independent of the cell 
content (only the style is used for other cells) and should be treated as the 
@dcsn in the regard, that the style is only used, if a cell lying in this 
range does not specify a style on its own. This would support style storage 
implementations like the Gnumeric one as I already mentioned.

> So regardless what the intended purpose of the 
> attribue was, it seems to be very reasonable to apply it only to those
> cells that have a cell element in the document.

I can't conclude this from the above.

> >>The clarification request further contains the following suggestions:
> >> > 1. Split the third paragraph of 8.1 "Basic Table Model", so it becomes
> >> > more obvious, that the rendering part belongs to both kind of apps. It
> >> > would also increase the readability.
> >>
> >>This seems to be reasonable. I propose that we add a paragraph break
> >> before the sentence that starts with "All other applications typically".
> >
> > The rendering paragraph I refered to starts actually at "Incomplete rows
> > are basically ...".
>
> In my opinion, this sentence belongs to the "All other applications"
> part of the paragraph. The spreadsheet case has been described already a
> couple of sentences earlier (starting with "When loading a table with
> empty or incomplete rows into a spreadsheet application").

Okay, in the thread on the comment list I splitted the paragraph to show, that 
issues arise, if the @dcsn is interpreted in the 'used area' way. These would 
vanish with your additions to the @dcsn definition. So, you can split the 
paragraph at this point, if you like.

> >> > 3. The spec should be extended to make use of the brevity approach.
> >> > E.g. by introducing two cell attributes "style-columns-repeated"
> >> > and "style-rows-repeated". A cell, lying in the repeated range, use
> >> > this style, except the cell sets its own. The repeated range belongs
> >> > to the used area. This would be even more flexible and brevity comes
> >> > to its optimum, because you can define style repetitions starting at
> >> > an arbitrary cell instead of being fixed to columns or rows.
> >>
> >>This actually is a request for an enhancement. We may consider this for a
> >>post 1.1 version of OpenDocument
> >
> > Cell style assignments to whole rows/columns are not possible with the
> > current spec as sheet dimensions between spreadsheet apps differ. But
> > these should be included sooner or later. If we stay with this odd
> > interpretation, that the @dcsn applies to the used area only, we have to
> > add another attribute to the row/column (style) element and things will
> > get messed up.

My interpretation of messy is a bit strict (maybe because of my scientific 
branding, which let me head for elegance ;-) ):
We probably end up with the @dcsn, which is applied to the used area, and 
another attribute naming a cell style, which will be applied to all cells in 
a column/row. That already hurts my aesthetic sense. :-| Last but not least, 
because the current spec is ambigious enough to allow a change to the better 
even if the spec is already public.

If we add the proposed cell attributes in a later version of the spec, these 
would make the @dcsn attribute redundant. As it allows a more generic style 
storage, the @dcsn should then be marked as obsolete. But apps will have to 
provide backward compatibility and should at least be able to read and 
interpret the @dcsn. If an app will be able to interpret the proposed cell 
attributes, it will automatically be able to interpret the @dcsn, so no 
problem here. But the @dcsn will become part of a rat tail of backward 
compatible attributes and this is what should be avoided. As I already said, 
the spec is still ambigious enough to achieve this.

> > The proposed additional cell attributes could be used to apply a style to
> > the used area only, while the @dcsn could be used for cell styles for the
> > whole row/column. That was the idea behind the proposal. This would be
> > more
>
> Can you describe in more detail what formating properties you would like
>   to have applied to the full rows/columns. Maybe it is an option to to
> add them to the row and column styles instead.

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 
such an interpretation for the @dscn. We could also add another attribute 
naming a cell style, but what I really don't want is to let cell style 
attributes become column/row style attributes!

Regards,
Stefan

PGP signature