Created attachment 17403 [details]
proposal for number-columns-spanned on table-column

Gerhard,

I see you made the same mistake (?) in interpretation of the Rec that I initially made: the Rec states 
literally that "the column-number for a fo:table-column is 1 plus the column-number of the previous 
column", if any. IOW, it is not because the first column 'spans' two columns, that the second column has 
initial value 3 as column-number... 
What it does mean, AFAICT, is that a fo:table-cell that has column-number 1 will automatically span the 
first two columns, such that a following cell having 2 as column-number will cause an overlap.

The code you offer for number-columns-repeated is interesting, but would fail IIC, unless the repeated 
column is really cloned. If not, then forceColumnNumber() --whatever that method does-- will most 
likely also alter the column-number of the base column (not only the repeated copy).


My 0.02$

Cheers,

Andreas

Finaly I would say, that my point of view is not better than the current
implementation. So i would propose to document the decision in the source of
fo/flow/Table.java to prevent others to go the same route (based on rec 7.26.12
"number-columns-repeated") before they recognize that there is a inconsistency
with 7.26.8 "column-number".

Something like this (feel free to alter or shorten)

if (colRepeat > 1) {
//in case column is repeated:
...
//there is an inconsistency for the column-number of table-column in the w3c
xml-fo rec between 
//7.26.8 "column-number": column-number of previous table-column + 1 
//and 7.26.12 "number-columns-repeated": column-number = previous +
number-columns-spanned
//fop developers decided to implement the behavour of 7.27.8
//see discussion on fop-dev mailing-list in 01/2006


After inserting something like that it is ok for me to close the bug.

resetting P2 open bugs to P3 pending further review