[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: Feedback on Comment list
On Monday 04 September 2006 20:58, Michael Brauer wrote: > Tables: default-cell-style-name interpretation > > http://lists.oasis-open.org/archives/office-comment/200607/msg00003.html > > This is a clarification request for the "table:default-cell-style-name" > attribute described in section 8.1.2. The current attribute description is: > > "The table:default-cell-style-name attribute specifies a default cell > style. Cells contained in the row without an individual cell style use > these default cell style." > > There was a long discussion on the user mailing list regarding the > interpretation of this attribute, and the essential question seems to be > whether the attribute should be applied to cells that are displayed by > typical spreadsheet applications (because they usually display sheets as a > very large/indefinite table), but are not contained in the table stored in > a file. > > Actually, I think that the OpenDocument specification shall only specify > the behavior for cells that are actually contained in the document. An > application may of course display more cells, and typical office > applications usually do so, but it is up to the application to decide how > to render them. I therefore think that the current description is > sufficient, because it specifies what happens for cells that are contained > in the document, and makes no assumptions for others. 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 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 ...". > > 2. Clarify, that the spreadsheet loading part refers to the dimension of > > the spreadsheet app, not the dimension of the saved doc. It's already > > given by 'just like in an empty sheet', but obviously it's not definite > > enough. > > Actually, the "spreadsheet loading part" always refers to the dimension of > the saved doc, and never to dimension of the table that is displayed by an > application. I therefore propose to not change this. As the loading is described explicitly for spreadsheet applications, it should be obvious, that there has to be a difference to other kind of applications. And this difference is IMHO the dimension of the table. > > 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. 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 consistent as all other row/column (style) element attributes are used to render also the cells outside the used area (e.g. dimension, visibility). And as styles are THE render instructions par excellence, an exception for this attribute makes not much sense. Further the transition to the proposed new attributes should (I don't know the code good enough) be not that hard for OO Calc. The style name has to be stored in a cell (often the first) instead of in the column/row element. Also style storage implementations, that store the styles in rectangular regions, separately from the cell instances, will benefit from this approach. This storage implemention is at least planned for KSpread and is AFAIK already used in Gnumeric. Just my two cents, but I saw, that your proposal was already discussed/accepted in the telecon on 2006-08-28. Regards, Stefan
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]