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

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.



Reply via email to