On 26.03.2005 16:05:46 Andreas L. Delmelle wrote:
> > -----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...
You may not have a first cell for every row. Take this example:
table
table-body
table-row
cell rowspan=3
cell rowspan=2
table-row height=50
table-row height=20
cell
In this example you don't have a first cell for the second row. If in
collapsing border model, the second row has a dominant border for start
and end edges, you're in trouble. Of course, this is a constructed
example, but maybe there are also real-world cases that may prove
problematic. A more realistic example would be a dominant border in the
third row for the after edge. You need to have a way to collect all
relevant borders for each border segment and I currently don't see how
you would do that.
> 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...
I understand your idea but I don't see (yet) how this can work out. For
the moment anyway, I have a different problem. I still need too figure
out how to handle page breaking for tables in the Knuth model. This
seems to be a rather critical point to me ATM. It all sounds nice and
easy in theory but I'm currently at a loss determining how to actually
implement it in a not too complicated way.
Jeremias Maerki
