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

Reply via email to