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


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.


While we're at it, add an implementation for the starts-row and ends-row
properties. Still mapped to, so
for starters, change the mapping in to make an
EnumProperty for them. In, 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.


Reply via email to