-Original Message-
From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
Hi,
(OK, apologies for my alias turning up... Completely unintended.
here's the remainder of the response. Other comments, much longer than the
previous one...)
On 17.05.2005 23:24:55 Andreas L. Delmelle wrote:
snip /
The current fact that there's an explicit reference to the
border-*styles* in an essentially layout-related class...
Well, somehow it does not sit completely right with me --could
be a matter of taste, but IMO, layout needs to concern
itself only with sizes...
That was a natural outcome since there are certain specialities in the
collapse model. If you look closely there's a little special case
where the collapsed border between two cells has the same style and
width but potentially different colors. If you follow through the rules
1 to 5 you end up in rule 5 solid 0.5pt red specified in one cell,
solid 0.5pt green in the neighbouring cell. See
table-border-collapse1.xml in testcases for an example. There's no rule
that says how to decide which of the two wins.
Very good point! Still, I would argue in that case that the layout engine
only needs to know that the border is going to be 0.5pt wide in case of no
breaks/spans. It is, strictly speaking, only when rendering the borders that
the implementation has to know for sure which colour to use.
If we are at liberty to determine that rule ourselves, I would obviously
feel much for an approach like 'before/start cell wins' or 'after/end cell
loses', and this as early in the process as possible. That would be very
convenient. Another idea is to use the color value to decide, or if you
really want a nasty solution that is bound to turn up in a bug report: XOR
the color values. A bug?? Shame on you for having no sense of humour! Read
the CSS Spec and study your table-border source very closely. It's *all* in
there! :-)
Furthermore, looking at those rules again, you will see that the style
is used to determine winners, styles having implicit precedence values.
Yes, but this could also be done when creating the FObjs --the styles map to
a numeric constant anyway. If we place them in the right precedence-order in
the Constants interface(*), we might not even need to assign precedence
values in a separate step. We'd directly use the integer value they map
to...?
That's why you need them aside from having to pipe such information
through to the addAreas() stage where the traits are set.
So, I would seem to disagree? Up until the 'aside from': the _latter_ part
is obviously necessary...
If you're talking about the border resolution you can't avoid looking at
the style, too. After that, in the table stepper, only the widths are
relevant.
Getting hotter, I feel it! :-)
snip /
I still think you're not quite where I am. Take the following methods:
- TableContentLayoutManager.resolveNormalBeforeAfterBordersForRowGroup()
- TableRowIterator.resolveStartEndBorders()
These are the two isolated places where the border resolution for
non-break cases are done. After that, the table stepper simply fetches
the table widths from the grid units to do the right calculations.
... and a large part of what happens in the above two methods --in the
background-- would already be dealt with in the FOTree, so the *only* parts
of the code remaining there would be dealing with the break-cases and the
span-cases. Very layout-specific stuff indeed!
Quite simply put: if a GridUnit corresponds with exactly one TableCell, in a
collapsing model, the *only* border-widths you'd really need to take into
account would be those of its TableCell. The rest I see as ruled out at that
point, *unless* in the following three cases
- after-border = still need to compare that to the Cell/GridUnit
immediately below
- row/column-spans = check the appropriate TableRow/TableColumn for start-
or end-borders
- page-breaks = check the TableBody/-Header/-Footer for the before- or
after-borders
The part where I gave up for now was how exactly to handle the
border resolution for break situations and how to bring the values into
the overall calculation.
Resolution to be done by layout in the break-situations would come down to:
* First, compare after-border with GridUnit below.
This step is always taken (see above) and yields
the after-border in no-break situation.
The dominant border is used in the following step.
* Then, only before- or after-borders matter here, so
either the current GridUnits' TableCell
(possibly corrected through the first step)
or the TableBody/-Header/-Footer
will yield the right border-width.
Resolution between TableCell and TableRow would already have been handled in
the FOTree. Same goes for the resolution between TableColumn and
TableBody/-Header/-Footer. If the order of fo:table-header, -footer
and -body is enforced by the Rec --so, header and footer *have* to appear
before body in the FO source--, then the same could be
