Re: Funny side-effects from space-resolution
On Wed, Sep 28, 2005 at 10:48:11PM +0800, Manuel Mall wrote: Jeremias, looks OK to me although a bit strange but hey...that's the spec. On Wed, 28 Sep 2005 10:00 pm, Jeremias Maerki wrote: I've just stumbled over the testcase block_margin_inherit while fixing problems revealed by the test suite after having space-resolution work on blocks. Here's how it looks like: fo:flow flow-name=xsl-region-body fo:block margin=5% background-color=yellow fo:block margin=inherit background-color=blue margin=inherit - should have the same margin as the enclosing block /fo:block /fo:block fo:blockYellow block has margin=5% - 18pt margin based on 5in page width/fo:block /fo:flow The 5% in this case evaluate to 18000mpt. margin, as a short-hand, results in space-before and space-after of 18000mpt each, and that for both blocks. In terms of 4.3.1 Space-resolution Rules, we have two sequences of space-specifiers due to stacking constraints. On the before edge, we have case 1 (under 4.2.5 Stacking Constraints), and on the after edge, we have case 2. Agree All space-specifiers are not conditional, because of 5.3.2 (last sentence in first paragraph). So, rule 1 in 4.3.1 does not suppress any space-specifiers. Rule 2 doesn't apply, either, since no space-specifier is forcing. Going on to rule 3 we have to collapse the two space-specifiers to one. Agree What's the effect? The test now fails because the space-resolution wasn't taken into account. Furthermore, the result looks funny due to the background colors. Both times it's the last space-specifier that survives (rule 3, second part) and I'm strictly taking the last by looking at the block-progression-direction here. Agree I agree with your arguments. If I understand you correctly then this implies that the resulting space-start is 18000mpt, blue, and the space-end is 18000mpt, yellow. But I do not see that in the attached pdf file, in which the space-start is yellow and the space-end is blank. Simon So this may be a somewhat unexpected result but I think it's correct. If anyone could verify that, I'd be grateful. Agree I'm attaching the PDF output of my local code. Jeremias Maerki Manuel -- Simon Pepping home page: http://www.leverkruid.nl
Re: Funny side-effects from space-resolution
On Thu, 29 Sep 2005 04:53 pm, Simon Pepping wrote: On Wed, Sep 28, 2005 at 10:48:11PM +0800, Manuel Mall wrote: Jeremias, looks OK to me although a bit strange but hey...that's the spec. On Wed, 28 Sep 2005 10:00 pm, Jeremias Maerki wrote: I've just stumbled over the testcase block_margin_inherit while fixing problems revealed by the test suite after having space-resolution work on blocks. Here's how it looks like: fo:flow flow-name=xsl-region-body fo:block margin=5% background-color=yellow fo:block margin=inherit background-color=blue margin=inherit - should have the same margin as the enclosing block /fo:block /fo:block fo:blockYellow block has margin=5% - 18pt margin based on 5in page width/fo:block /fo:flow The 5% in this case evaluate to 18000mpt. margin, as a short-hand, results in space-before and space-after of 18000mpt each, and that for both blocks. In terms of 4.3.1 Space-resolution Rules, we have two sequences of space-specifiers due to stacking constraints. On the before edge, we have case 1 (under 4.2.5 Stacking Constraints), and on the after edge, we have case 2. Agree All space-specifiers are not conditional, because of 5.3.2 (last sentence in first paragraph). So, rule 1 in 4.3.1 does not suppress any space-specifiers. Rule 2 doesn't apply, either, since no space-specifier is forcing. Going on to rule 3 we have to collapse the two space-specifiers to one. Agree What's the effect? The test now fails because the space-resolution wasn't taken into account. Furthermore, the result looks funny due to the background colors. Both times it's the last space-specifier that survives (rule 3, second part) and I'm strictly taking the last by looking at the block-progression-direction here. Agree I agree with your arguments. If I understand you correctly then this implies that the resulting space-start is 18000mpt, blue, and the space-end is 18000mpt, yellow. But I do not see that in the attached pdf file, in which the space-start is yellow and the space-end is blank. Simon, I don't think padding is suppose to extend into the space-before/after areas. So we have an 18pt space-start that is blank for the outer block which is repeated as space-after as well. The yellow background defined on the outer block covers the space-before/after of the inner block (= padding rectangle of the outer block). The blue background covers only the padding rectangle of the inner block. Simon Manuel So this may be a somewhat unexpected result but I think it's correct. If anyone could verify that, I'd be grateful. Agree I'm attaching the PDF output of my local code. Jeremias Maerki Manuel
Funny side-effects from space-resolution
I've just stumbled over the testcase block_margin_inherit while fixing problems revealed by the test suite after having space-resolution work on blocks. Here's how it looks like: fo:flow flow-name=xsl-region-body fo:block margin=5% background-color=yellow fo:block margin=inherit background-color=blue margin=inherit - should have the same margin as the enclosing block /fo:block /fo:block fo:blockYellow block has margin=5% - 18pt margin based on 5in page width/fo:block /fo:flow The 5% in this case evaluate to 18000mpt. margin, as a short-hand, results in space-before and space-after of 18000mpt each, and that for both blocks. In terms of 4.3.1 Space-resolution Rules, we have two sequences of space-specifiers due to stacking constraints. On the before edge, we have case 1 (under 4.2.5 Stacking Constraints), and on the after edge, we have case 2. All space-specifiers are not conditional, because of 5.3.2 (last sentence in first paragraph). So, rule 1 in 4.3.1 does not suppress any space-specifiers. Rule 2 doesn't apply, either, since no space-specifier is forcing. Going on to rule 3 we have to collapse the two space-specifiers to one. What's the effect? The test now fails because the space-resolution wasn't taken into account. Furthermore, the result looks funny due to the background colors. Both times it's the last space-specifier that survives (rule 3, second part) and I'm strictly taking the last by looking at the block-progression-direction here. So this may be a somewhat unexpected result but I think it's correct. If anyone could verify that, I'd be grateful. I'm attaching the PDF output of my local code. Jeremias Maerki block_margin_inherit.xml.head.pdf Description: Binary data