Re: Funny side-effects from space-resolution

2005-09-29 Thread Simon Pepping
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

2005-09-29 Thread Manuel Mall
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

2005-09-28 Thread Jeremias Maerki
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