> -----Original Message-----
> From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED]
>
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)
The requirements for this I see up to here are roughly as follows:
In fop.fo.flow.TableBody
- add a protected TableRow member variable, and
- override fop.fo.FObj.addChild to assign the caught row event to it,
instead of creating an FObj child for every encountered row and adding it to
its children ArrayList (=default FObj behaviour).
If a child to be added to the TableBody is a TableCell and the first child,
insert one TableRow anyway --will come in handy further downstream.
Also in fop.fo.flow.TableBody, introduce a variable to hold the current cell
being added.
In fop.fo.flow.TableRow, override fop.fo.FObj.addChild, and make it :
- add the child to its parent TableBody when it starts a row, or
- assign the child as next cell to the TableBody's currentCell
The idea being that the cells are added to the TableBody as chains. Only the
row-starting cells are direct children of the TableBody. The others are
referenced by a nextCellInRow variable in the previous cell (--dunno for
sure about this :/ )
What it comes down to, is trading this structure
TableBody
TableRow (->columns: ArrayList of TableColumns)
TableCell
TableCell
...
TableRow (->columns: ArrayList of TableColumns)
TableCell
TableCell
...
for
TableBody
TableRow (->columns: ArrayList of TableColumns)
TableCell (->nextCellInRow: TableCell (->nextCellInRow: null))
TableCell (->nextCellInRow: TableCell (->nextCellInRow: null))
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...)
In case the Table didn't have any columns specified, this is where they can
be added/derived. If the TableRow's columns ArrayList is set to reference
the one from the parent Table in the TableRow's constructor or init(), we
could test in addChild() whether it is null: in this case create the columns
and add them to the TableRow's column List as the TableCells are added. In
the TableRow.end() method, set the columns List for the parent Table if it
is still null. For each subsequent TableRow being processed, the columns
List will be readily available from the parent Table. (IOW: this facilitates
implementing the 'columns-are-determined-by-cells-in-the-first-row' part)
? My question here is whether this can be done in TableRow.addChild() by a
simple:
TableColumn col = new TableColumn( (FONode)getParentTable() );
/* set width from current cell if known, else defer this setting
/* until the List is passed back to the Table, and use a
/* formula like: Table.OptIPD / ColumnCount, possibly
/* refined to include widths of other Columns that *were*
/* explicitly set
/* DON'T add the column to the Table just yet ... */
columns.add( col );
then later on in TableRow.end(), something like:
getParentTable().setColumns( columns );
?
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)
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.
Just food for thought... hope someone enjoys :)
Now, back to work.
Cheers,
Andreas
