Another detail overlooked is the column-number property, ...
Which is, for the moment quite ... unimplemented (--should've checked this sooner :) ), so that explains why the spec isn't being followed when setting the default value to 0.
This makes me think that much of colspan and rowspan could already be managed at FO Tree level, so the LM's already get supplied the correct value at least for colnr from interrogating their FObj. I would judge this approach to be much cleaner... Any thoughts on this?
it would be easy to determine col number in Table.addChild. This number could then be replaced in TableColumn.doSetup only if Column Number has actually been specified in the FO. I'm not sure I would be keen on working out any spanning related stuff in the FO Tree classes as it seems the wrong place for such computations. But that is just an opinion.
With the current modifications I have made to the cell & row LM's (--more on these soon), it should work... when support for the column-number property would be available. That is: for the moment, I have column-span working correctly apart from the fact that the column-number is always 0. If this is not the case, as I could see when hacking this support into the row LM in setupCells(), the cellIPD and xoffset for the following cells are being calculated correctly, based upon the correct table-column. (This was done in such a way that we can easily pick up the column-number from the corresponding TableCell afterwards, if and when we figure out how to correctly set the defaults for this.)
The RowSpanMgr in maintenance *is* indeed very interesting... still no luck here, though
I dont follow, could you elaborate?