On Aug 27, 2005, at 22:22, Jeremias Maerki wrote:
On 27.08.2005 21:33:44 Andreas L Delmelle wrote:
I'm wondering, for instance, whether the table's before-border specs
are only relevant for the first page that is spanned by the table. For
example: in case the table has a header (and
omit-header-at-break="false"), and the table's before-border wins,
then
it can still *appear* on the following pages (but that will be because
it *is* the header's before-border).
No, the table only has an own border in the separate border model. In
the collapsing border model only cells have borders. The FO spec is
very clear on that. So it's absolutely normal that the border specified
on the table-level can reappear on the following pages based on who
ever
wins.
I see. That seems to be exactly what I expected (although again, I
described it in the wrong terms).
To put it correctly: since the table before-border wins over header
before-border, it becomes the competing border for the before-borders
of the cells in the first row of the header. If all the cells in the
header's first row have the same before-border, the table's
before-border then becomes the before-border for all of them.
Sorry for my being unclear. The question was stated in terms of the
phase I'm currently working on: resolving the border-conflicts between
the table and its header/footer/bodies, and those between the
header/first body, body/body, last body/footer. The deeper table
elements will be something for next week.
<snip />
(so in this simplified case the after-border on one page
will *always* be the same as the before-border on the next)?
No, I don't think so. I believe the collapsing only happens between two
effectively adjacent cells, i.e., translated to one of our stages, more
located in the area tree stage than in the FO tree stage, if you know
what I mean. But I'm not sure here, because I think the spec is really
not that clear in this little detail. But I'd also think it would be
strange if the border after from the previous page would bleed over to
the next page in this way.
OK, that means resolving after/before border conflicts between two
bodies would need to be deferred to layout.
Thanks for the useful comments.
BTW: since it is my intention to facilitate the job of the layout
package in this matter, I'm considering adding BorderInfo instances
(although I'm not sure where exactly) that keep the resolved info to
use precisely in these layout-specific cases. What I mean is: even if
the FOTree lacks some of the context, there is always the fact that it
is a possibility (however remote) to have a page-break between two body
elements.
We could say: the BorderInfo to use in 95% of the cases is the one that
is immediately available in the element's CommonBorderPaddingBackground
instance, in the other 5% it's another one, available 'over there'
(wherever that is). Layout would then not need to re-evaluate, but pick
up the width from that 'special' BorderInfo instance.
Does this sound like a sane thing?
Cheers,
Andreas
