- From: Vincent Hennebert <vincent.hennebert@anyware-tech.com>
- Date: Wed, 04 Apr 2007 21:10:11 +0200
- To: xsl-editors@w3.org
- CC: fop-dev@xmlgraphics.apache.org
- Message-ID: <4613F813.2020003@anyware-tech.com>
Dear XSL Editors, I have another question regarding border- and padding-conditionality. Please see the attached fo file, which gives a two-page document: the question is whether the padding-before of the inner block should be discarded or not on the second page. The intuitive answer would be yes (at least I think this is what most users would expect). However, if we strictly follow the rules of the XSL-FO 1.1 Recommendation it seems that the padding should actually be retained. Indeed it would be discarded if the before-edge of the area generated by the inner block were a leading edge in the normal-flow-reference-area (of the second page, let's call it R). This is explained in the last two paragraphs of section 4.3.1, "Space-resolution Rules" of the XSL-FO 1.1 Recommendation. This edge would be a leading edge if the inner blocks's area would begin the normal-flow-reference-area (section 4.2.5), that is if it had a stacking constraint with R and if none of its ancestor areas had a non-null space-before. However, the retained border on the outer block creates a fence before the area generated by that block; which prevents the inner area from having a stacking constraint with R. Thus the edge is not a leading edge and the padding-before should be retained. What is interesting is that if the outer block had a discarded border-before then the padding would also be discarded, as this time there would be a stacking constraint between the inner area and R. Also, if the outer block were instead a block-container, then the padding would again be discarded, because the reference-area to be considered would be the one generated by the block-container. One developer came up with an interesting interpretation: the rules at the end of section 4.3.1 should be taken only to determine if border and padding create fences preventing stacking constraints to occur (as seems to be implied by the "for purposes of the stacking constraint definitions" sentence). And that the notion of leading/trailing /area/ should instead be considered to determine if borders and padding should actually be discarded or not. While this interpretation makes sense and would match users' expectations, I'm not sure if it is really intended by the Recommendation. So could you please provide a clarification on this subject? Thanks, Vincent Hennebert
Attachments
- text/x-xslfo attachment: border-padding_conditionality.fo
Received on Wednesday, 4 April 2007 19:11:52 UTC