Andreas L. Delmelle wrote:
comments below:
Posting this as a follow-up to my earlier ponderings. If we don't get it implemented, or postpone this one indefinitely, at least we'll have it nicely summed up for possible future use... (Who knows, maybe parts of these remarks can be used to implement the starts-row and ends-row properties for table-cells)
<snip/>
If we manage to make it possible for the Layout Managers to deal with the latter, this would allow us to support tables with or without explicitly defined rows with greater ease (i.e. one strategy fitting both situations). Difference: in a 700-row table, you'd only have one TableRow FObj instead of 700 that remain referenced until the page-sequence is completed... (admitted: it does enlarge the TableCell objects a bit...)
Yes, just what I was thinking. TableCell would be quite complicated. Although it is hard to gauge by just talking about it.
<snip/>
While we're at it, add an implementation for the starts-row and ends-row properties. Still mapped to fop.fo.properties.ToBeImplementedProperty, so for starters, change the mapping in fop.fo.FOPropertyMapping to make an EnumProperty for them. In fop.fo.flow.TableCell, add the necessary code to the doSetup() method to make it possible to actually use them... (is there another step I'm missing?) (Come to think of it: the 'width' property for table-cells seems also unimplemented for the moment)
This makes sense - what effect would you expect width on table cell to have? I maybe missing something, but the width is derived from table column and cant be overridden for a single cell.
Modifications in Layout: as already indicated, I think there are not that many. It will continue to work as it does now. It's only the LM *creation* process that will need a little tweaking... As there will always be a TableRow child present, even if there was none specified in the source FO, the first Row LM will be created anyway. It will just be a matter of adding the Cell LMs as children of the current Row LM, and generating a new Row LM when the Cell in question starts a row.
So, for those of you that have read closely (--and have been able to keep awake ;) ): Indeed, it seems as if I'm making things more complicated, since the rows are removed in the FOTree, but are re-introduced in Layout... This is because, AFAICT, the problem with big tables is mainly the creation of the FObj's, so this goes a little step towards solving that one. On top of that, while building the FOTree, it is hardly ever necessary to peek into preceding/following Rows, so the work over there (IMHO) doesn't really *need* multiple TableRow objects for one TableBody.
There may be a need to peek at surrounding rows when implementing border-collapse algorithms. Not sure if this peeking will need to be done in FO Tree or layout or both.
Just food for thought... hope someone enjoys :)
On the whole a very well thought out idea. I dont want you to think I'm discouraging you. You have answered my initial concerns, so why dont you go ahead and make the changes locally and then create a patch for review. It will be easier to discuss pros/cons in more depth by looking at the patch file.
Chris
