On Sep 16, 2005, at 12:26, Finn Bock wrote:
My take is that only a "true" value is used to determine a change in
row. It makes no difference to the fo-tree or to layout if a default
"false" or an explicit "false" is found.
FWIW: That was precisely my understanding too, hence my speaking of a
'contradiction'.
[7.26.15]
"""
The "starts-row" and "ends-row" properties with a "true" value are
typically used when the input data does not have elements containing
the cells in each row, but instead, for example, each row starts at
elements of a particular type.
"""
I found no indication that a "false" value can be used to prevent a
row change, so there is IMO no real conflict if conflicting values are
used on sibling cells.
Well, currently you both got me convinced about this. I'm working on it
--but a bit frustrated, since that was really the *only* case where it
failed. All other situations are handled nicely including row-spans...
--even when a user would only use ends-row to indicate row-changes, all
works as it should.
And now this... Aarrrghh!! :-)
Oh well, give it some time. I'm sure I'll come up with something. Have
already tried a quick hack, forcing the column-number, but then the
FOTree tests fail, because the value isn't correctly initialized in the
PropertyList itself (only the TableCell's instance variable is
altered).
Unfortunately no lookahead in the FOTree, otherwise I could just go
if( currentCell.endsRow() || nextCell.startsRow() ) {
//reset columnIndex
}
I'm beginning to see the advantages of XEP's approach to normalize
tables in a pre-processing XSL transform of the FO source document...
Anyway: thanks for your feedback.
Cheers,
Andreas
