> -----Original Message-----
> From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
> > Me:
> > However, instead of mapping both possibilities to a
> > structure with rows, we could go almost the other way
> > round ...
>
> 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.
<snip />
> 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.
Very good point indeed!
I even think that *that* was the point where I eventually had to stop and
breathe --slowly, to keep my head from over-heating :-)
Anyway: agreed 1000% --yes, a thousand--, as long as one really needs an
fo:table-cell node in the source document to trigger the instantiation of a
TableCell (or subclass) FONode...
I guess what I'm suggesting would, in your constructed example, come down
to:
table
table-body
cell rowspan=3 starts-row=true row-border=...
border=...
cell rowspan=2 border=...
cell starts-row=true row-height=50 row-border=...
cell starts-row=true row-height=20 row-border=...
cell border=...
The fact that the first of the above cells spans 3 rows, would mean that the
third and fourth cells' *only* possible function is exactly to store the
row's properties.
We wouldn't lose these properties, they would just 'move' to a different
location (and they would still be considered separately from the
cell-particular properties --think of it as a cell with two 'bundles' of
properties)
BTW: the cells' column-number also appears to be pretty crucial in the
approach I'm trying to describe...
<snip />
> 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.
Oh, of course. I just saw the opportunity to unleash some of my ideas, but I
see now that it is indeed not really relevant to the initial topic of this
thread --sorry 'bout the unnecessary distractions.
> 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.
Nothing you should be worrying about right now. Stay focused on whatever
you're doing, and don't let it distract you too much --it's clear that I am
the one who needs to give this more thought, while keeping a closer eye on
what you're doing :-)
Cheers,
Andreas
