> -----Original Message-----
> From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
>

(Just trying to join in the conversation with no specific knowledge about
the code yet --still catching up on the recent changes--, but I remember
that, a while ago, I had also been struggling with tables. The code will
have changed a lot I guess, but some of the options I considered could be of
use... I hope)

> I tend to think by now that the first approach I presented earlier is
> illusory and too complicated. The second should work out just fine, even
> with row span.

Speaking of rowspan: I don't really know if it's even possible, but one of
the options that kept haunting me --and thus, seemed promising to me-- was
to not create a rowLM for every cell-list (to bridge the gap between
'rowless' and 'explicit rows'), but rather use one rowLM as a sort of 'comb'
(if the analogy makes sense).
A cellLM for a fo:table-cell spanning multiple rows --and its children--
would remain in the rowLM until the cellLM's 'remaining' rowspan becomes
zero (span here being relative to the page to accommodate cells spanning
multiple pages). The rowLM _can_ receive its properties from the current
fo:row, if there is one. If not, these props can be null-ified.
WRT the column props, my attention had been drawn to the fact that a
columnList was created for _every_ row, since these:
 a. basically stay the same for the whole table in the easiest cases
 b. for the harder cases they are (very) roughly constant for a
cross-section of
   1. region of the page (static or flow; possibly multi-column itself)
   2. (table-header +) table-body (+ table-footer)

Recreating a reference to a list with references to the columns for every
row seemed to be inefficient somehow --very much so in case of a table
spanning across many pages containing hundreds, possibly thousands of rows,
even with only seven or eight columns...

My main motivation for considering such a construct was the fact that, at
the Area Tree level, there *is* no row, only the union of the areas
generated by its children, so it seemed to make sense to diminish the
importance of the row-concept when progressing from FO Tree --multiple-- to
Layout Tree --one, maybe two or three, but no more-- to Area Tree --zero.

With a few helper rows, it also seemed attractive from the POV of 'marking'
the earlier described cross-section. Convenient to iterate --in both
directions-- over the elements in the table (body|header|footer)'s element
list (the cellLMs), and perform multiple passes, since the first and last
row on a page contain the necessary references to the bounding elements in
the element-sublist in question. Go for a 'rough sketch' pass first, if this
is not sufficient --which conditions exactly?--, iterate over the altered
elements.

> I'll start with the helpers for keeping track of accumulated BPD.
> In the meantime I hope there's enough time so you guys can comment on
this.

Well, possibly more detailed, code-oriented description to follow...

I hope there's a 'Aha!-Erlebnis' in there somewhere for someone.
If not, I hope you at least enjoyed the rant :-)
If not --errm... my apologies.


Greetz,

AD

Reply via email to