On Mar 28, 2007, at 10:25, Vincent Hennebert wrote:

<snip />
Comparing FO to PDF, my common sense jumps up and says:
"Why do you expect the padding to be retained at page-breaks, when
specifying .conditionality='discard'?"

Precisely because of this notion of "fence".

OK ... and does the notion of a 'fence' also apply to padding?

If the padding is conditional, yes. There is a fence preceding an area
(here the area generated by the outer-block) as soon as it has a
non-null border-before or padding-before (XSL-FO 1.1, 4.2.5).

OK, I understand the idea that there is a "fence preceding", but I still don't see precisely where this fence would have any impact on the treatment of conditionality of the border or padding.

I'm wondering if your confusion is not caused by the fact that space- properties can also be specified as conditional, and there is a very subtle difference between conditionality in the cases of: 1) a space-specifier: "a compound datatype whose components are minimum, optimum, maximum, conditionality, and precedence" (space-* properties) 2) a plain and simple length-conditional: which is the possible datatype for the border-* and padding-* properties (no .minimum, .optimum, .maximum or .precedence components)

And in 4.3.1: if the border-before or padding-before is conditional,
then it is set to 0 if the before-edge of the allocation-rectangle is a
leading edge in a reference-area... which is not the case here for the
inner block.

... but again: 4.3.1 deals with /space/-resolution.

Reading a bit closer:
"The padding of a block-area does not interact with any space- specifier (except that by definition, the presence of padding at the before- or after-edge prevents areas on either side of it from having a stacking constraint.)"

Now, if I interpret correctly, this means that the border/padding itself acts as a fence in the space-resolution. "The border or padding at the before-edge or after-edge of a block- area B may be specified as conditional. If so, then it is set to zero if its associated edge is a leading edge in a reference-area, and the is-first trait of B is false, or if its associated edge is a trailing edge in a reference-area, and the is-last trait of B is false. In either of these cases, the border or padding is taken to be zero ***for purposes of the stacking constraint definitions***"

A matter of interpretation, maybe, but I would say that if an area B' is the first child area of the described block area B and B is leading in a reference-area, then the associated edge on B', ***for the purposes of resolving border and padding conditionalities***, can be considered to be a leading edge in that same reference-area.

If not, then there would be no way whatsoever to keep border and padding on nested blocks from being retained at page-breaks. :/



Cheers,



Andreas



Reply via email to