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] merging nested tables with surrounding table


Thomas

This confirms what I was suspecting, namely that such a model will be 
quite difficult to handle, especially when the spans can be used to 
express the same thing.

I think the borderModel property you mention only applies to cells 
within the same table (like CSS border-collapse.

Given that a requirement to make nested tables appear to be part of the 
surrounding table, it might be better to specify something along the 
lines of: If table:merge-with-surrounding is set to true, the cell 
contents (including any borders) of the enclosing cell are entirely 
replaced by the nested table (including any borders). See the attached 
image for an example.

Anyway - I don't think we need this until someone proves otherwise (by 
providing a relevant use-case).

/Lars

Thomas Zander wrote:
> On Wednesday 27 June 2007 13:26:12 Lars Oppermann wrote:
>> I think it would be possible to define a table style property in ODF,
>> which specifies, that a surrounding cell border becomes the outer
>> border for a nested table. I am unsure whether there is realy a
>> requirement for such a feature as rowspan/colspan can be used to
>> achieve the same visual result.
> 
> Hmm, not sure if this mixes very well with the "Collapsing border 
> model" [1]
> 
> In this model the border should be 50% in the one cell and 50% in the 
> other cell.  Which will get very complex and weird with the suggested 
> model as the underlying model gets abused quite a lot if it has to do 
> what the user expects.  That is; act like the B1 actually has a colspan 
> of 2.
> 
> We should accept that when the user actually means to use colspan/rowspan 
> from a user interface perspective we should make the tools to handle that 
> more intelligent so its not too cumbersome compared to subtables.
> Altering the fileformat to allow a workaround (the subtables structuring) 
> to be saved seems wrong in my book.
> 
> 
> 1) 
> http://testsuite.opendocumentfellowship.org/testcases/FormattingProperties/TableFormattingProperties/borderModelProperty/TestCase.html

PNG image



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