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
