You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Jeremias Maerki <de...@jeremias-maerki.ch> on 2005/09/28 16:00:29 UTC
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:block>Yellow 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
Re: Funny side-effects from space-resolution
Posted by Simon Pepping <sp...@leverkruid.nl>.
On Thu, Sep 29, 2005 at 05:03:39PM +0800, Manuel Mall wrote:
> On Thu, 29 Sep 2005 04:53 pm, Simon Pepping wrote:
> > On Wed, Sep 28, 2005 at 10:48:11PM +0800, Manuel Mall wrote:
> > 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.
You are right. I had not realized that the spaces are not in the
padding rectangle of their block.
Simon
--
Simon Pepping
home page: http://www.leverkruid.nl
Re: Funny side-effects from space-resolution
Posted by Manuel Mall <mm...@arcus.com.au>.
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:block>Yellow 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
Re: Funny side-effects from space-resolution
Posted by Simon Pepping <sp...@leverkruid.nl>.
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:block>Yellow 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
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Thanks Manuel!!!
On 28.09.2005 16:48:11 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:block>Yellow 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
>
> > 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
Jeremias Maerki
Re: Funny side-effects from space-resolution
Posted by Manuel Mall <mm...@arcus.com.au>.
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:block>Yellow 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
> 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