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 Nikolaus wrote:
> Hi Michael, hi all,
> On Wednesday 06 September 2006 16:02, Michael Brauer wrote:
>>"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 

Did you see my clarification proposal at


It actually states that the attribute is not applied to cell that has no 
<table-cell> element.

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

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

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

> 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 

It is not applied to the "used area". It is applied to the cells that have 
cell elements in the file. That's something different than the used area.

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


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