Re: More on border and padding conditionalities
Hi Andreas, Andreas L Delmelle a écrit : > 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) I'm telling you I'm not making the confusion ;-) Yes I have those points in mind. But more below. > 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. Yes. > "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. Hmmm, I see your point. You mean that for space-resolution (where the border/padding conditionality is used to determine fences), border and padding should be seen as leading /edges/. Whereas for border/padding conditionality itself (actual value of border/padding width for the area), they should be seen as before-edges of leading /areas/ (and same for border/padding after and trailing edge/area). That makes sense, but this is really an interpretation I think. The "then it is set to zero if its associated edge is a leading edge in a reference-area" above makes me seriously doubt of it. That said, that seems pretty logical and would probably match most expectations. > If not, then there would be no way whatsoever to keep border and padding > on nested blocks from being retained at page-breaks. :/ Well in most cases that would work as expected I think. Again here I'm thinking of power-users having studied every detail of the spec and counting on it to achieve special effects... and also of how that impacts the implementation of that stuff. Cheers, Vincent
Re: More on border and padding conditionalities
On Mar 28, 2007, at 10:25, Vincent Hennebert wrote: 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
Re: More on border and padding conditionalities
Hi Andreas, Andreas L Delmelle a écrit : > On Mar 27, 2007, at 10:47, Vincent Hennebert wrote: > >> Andreas L Delmelle a écrit : >>> On Mar 26, 2007, at 16:48, Vincent Hennebert wrote: > I'm having a lot of fun playing with border and padding conditionalities... > >>> >>> Just a sanity check: aren't you confusing padding-* with space-* here? >> >> No :-) > > OK, just thought I'd make sure. ;-P No problem! >>> 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). 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. > If this would be so, then similarly, one could argue that even if the > inner block's border-before has a conditionality of "discard", you'd > still expect it to be retained, because there is the 'fence' of the > outer block's border? Exactly, yes. Vincent
Re: More on border and padding conditionalities
On Mar 27, 2007, at 10:47, Vincent Hennebert wrote: Andreas L Delmelle a écrit : On Mar 26, 2007, at 16:48, Vincent Hennebert wrote: I'm having a lot of fun playing with border and padding conditionalities... Just a sanity check: aren't you confusing padding-* with space-* here? No :-) OK, just thought I'd make sure. ;-P 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 this would be so, then similarly, one could argue that even if the inner block's border-before has a conditionality of "discard", you'd still expect it to be retained, because there is the 'fence' of the outer block's border? Cheers, Andreas
Re: More on border and padding conditionalities
Hi Andreas, Andreas L Delmelle a écrit : > On Mar 26, 2007, at 16:48, Vincent Hennebert wrote: > > Hi Vincent, > >> I'm having a lot of fun playing with border and padding >> conditionalities... > >> I think the padding should actually not be discarded on the second page. >> It would if the corresponding edge were a leading edge in the >> region-body's reference area. However, it is not because there is no >> stacking constraint between the inner block's area and the (region >> body's) ref-area. Because the retained border on that inner block >> creates a fence which prevents rule 3.b (XSL 1.1, 4.2.5) to apply. > > Just a sanity check: aren't you confusing padding-* with space-* here? No :-) > 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". Actually it would even make sense to me that if the border-before is "retained", then the padding-before should also become retained. But it appears that the spec does not require that. In the case I've presented, the fact that the enclosing block has a retained border-before prevents the before-edge of the child block-area from being a leading edge in the page's ref-area. It results that the conditionality of its border and padding is not applicable. Follow me? ;-) I would be grateful if someone could confirm my thoughts. I'm wondering whether it's an intended behavior or an oversight resulting from the definition of leading edge. BTW, note the difference between "leading edge" (XSL-FO 1.1, 4.2.5) and "leading area" (XSL-FO 1.1, 4.8). The former applies to border- and padding-conditionality for non-first/last areas, the latter to rules for breaks and keeps. While there may be some relation between the two notions, this is generally not the case. As I was making the confusion until recently, I thought it might be worth telling it. ;-) Cheers, Vincent
Re: More on border and padding conditionalities
On Mar 26, 2007, at 16:48, Vincent Hennebert wrote: Hi Vincent, I'm having a lot of fun playing with border and padding conditionalities... I think the padding should actually not be discarded on the second page. It would if the corresponding edge were a leading edge in the region-body's reference area. However, it is not because there is no stacking constraint between the inner block's area and the (region body's) ref-area. Because the retained border on that inner block creates a fence which prevents rule 3.b (XSL 1.1, 4.2.5) to apply. Just a sanity check: aren't you confusing padding-* with space-* here? 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'?" Cheers, Andreas
