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

<snip />
> I haven't understood everything you wrote, yet. I think there's a spark
> of an idea in there but ATM I can't get hold of it. I'd appreciate if
> you could look at the current table layout code.

Just did.

> The change from first-fit to Knuth approach doesn't invalidate much of it.

Indeed not. What I'm referring to goes more in the direction of 'interaction
between FOTree and Layout', not so much the workings of the Layout system
itself --although it's bound to have *some* impact on it, this should be
minimal (and may even facilitate some of the work, but that's still a
question-mark for me)
It appears to me more an alternative to the current solution for bridging
the gap between tables with and without table-rows.

Currently both possiblities lead to the same structure in the FOTree, which
is perfectly legitimate --RenderX performs table-normalizing in a
pre-processing XSLT step, which deals with this amongst others (if I
remember correctly.. I only had a very quick look and that was quite some
time ago.)

However, instead of mapping both possibilities to a structure with rows, we
could go almost the other way round by using a structure with cells as
direct descendants from the body, where the first cell of each row would be
a special type (a subclass of TableCell?) that has the ability to store the
row's properties (if fo:table-rows are explicitly used). The 'starts-row'
property is there anyway, so it can be put to good use...

In the Layout Tree the RowLM's initialization would be triggered by these
row-starting cells, but the RowLM would operate on the cells as direct
descendants of the body. So the RowLM's cell-list would not correspond to
the unique list of descendants of a corresponding TableRow, but rather to a
sublist of the unique list of descendants of its parentLM's
TableBody/-Header/-Footer. (IOW: the RowLM's could be made re-usable; at
least, there would not *necessarily* have to be a one-to-one relation
between fo:table-row, TableRow and RowLM --although it still remains
possible where it *is* needed.)

I'm still not sure whether it makes sense...



Reply via email to