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

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

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


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


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.

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, or, even better, it may use a row or column 
style. 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. 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.

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

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

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.

Best regards

Michael



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