Re: The space resolution examples

[Jeremias Maerki <de...@jeremias-maerki.ch>]

On 30.09.2005 08:50:22 Simon Pepping wrote:
> Hi,
> 
> I have a problem with a number of examples on the Wike space
> resolution examples page. I wonder if I have a major misunderstanding.

And I wonder if I ever switched on my brain while writing those examples.
I made a number of mistakes like applying the is-first/is-last rule
defined only for border and padding to spaces, too. I clarified this on
the Wiki.

> In general, I have a different idea about the retain
> condition. Retained spaces do not appear between areas returned by the
> FO; all spaces appear before or after all areas returned by the
> FO. This is different from retained padding and borders.

That's the part where I think you are wrong. 4.2.3 and 7.10.5 make it
clear IMO that space-before|-after are applied to every area generated
by an FO. The following sentence is the key: "Specifies the value of the
space-specifier for the space before the areas generated by this
formatting object." (Notice the "areas"!)

> * Example 0
> 
> IMHO it should be: Here we look at the case where a break
> happens before "before break".

Doesn't matter IMO. It's the same outcome in both cases.

> * Example 1
> 
> IMHO it should be: The break after "first line" does not
> produce a 10pt space because the space is conditional.
> 
> and my element list is (case 'All spaces are conditional'):
> 
> box w=lh for "first line"
> 
> penalty w=0 p=0 for the break possibility after "first line"
> 
> glue w=10pt for the space in case there is no break
> 
> box w=lh for "before break"
> 
> penalty w=0 p=0 for the break possibility after "before break"
> 
> box w=lh for "after break"

Agreed.

> * Example 2
> 
> My element list is (case 'Only the first space is conditional'):
> 
> box w=lh for first block
> 
> penalty w=0 p=0 for the break possibility
> 
> box w=0
> penalty p=INF
> aux glue w=10pt for space-before
> 
> box w=lh for "before break"
> 
> penalty w=0 p=0 for the break possibility after "before break"
> 
> box w=lh for "after break"

Here we obviously disagree, but I had to fix the element list. It was
wrong.

> * Example 3
> 
> Break between the blocks:
> 
> Both space specifiers are conditional, and are suppressed due to rule
> 1 in 4.3.1.
> 
> My element list is (case 'All spaces are conditional'):
> 
> box w=lh for first block
> 
> penalty w=0 p=0 for the break possibility
> 
> glue w=10pt y=0 z=0
> 
> box w=lh for second block

Agreed.

> * Example 4
> 
> Break between the blocks:
> 
> The first space specifier is retained, the second is conditional, and
> is suppressed.
> 
> My element list is (case 'Only the second space is conditional'):
> 
> box w=lh for first block
> 
> glue w=10pt y=0 z=0
> 
> penalty w=0 p=0 for the break possibility
> 
> box w=lh for second block

Agreed.

> * Example 5
> 
> Break between the blocks:
> 
> Both space specifiers are retained.
> 
> That means that with a break we have more space than without a break,
> and we need a negative glue (glue #2) to compensate this.
> 
> My element list is (the full case glue #1 - penalty - glue #2 - box -
> PENALTY - glue #3):
> 
> box w=lh for first block
> 
> glue w=10pt y=0 z=0
> 
> penalty w=0 p=0 for the break possibility
> 
> glue w=-10pt y=0 z=0
> 
> box w=0
> penalty w=0 p=INF
> glue w=10pt y=0 z=0
> 
> box w=lh for second block

Agreed.

> * Example 8
> 
> The space-before of the block with "second line" is conditional, and
> therefore is suppressed.
> 
> My element list is (case 'All spaces are conditional'):
> 
> box w=lh for first line
> 
> aux glue w=6pt y=0 z=0
> 
> box w=lh for second line

Agreed.


In example 9 the reasoning was wrong.

Thanks a lot, Simon, for going through all this!

Jeremias Maerki

Re: The space resolution examples

[Manuel Mall <mm...@arcus.com.au>]

Sounds like you guys are converging along these line:

1. Space properties are set as traits on each area.

2. Appearance of spaces is (largely) controlled by a combination of the 
conditionality setting, being the first/last area of a reference area, 
and the presence of "fences" (non zero border / padding).

Manuel

On Thu, 6 Oct 2005 04:50 am, Jeremias Maerki wrote:
> On 05.10.2005 20:32:53 Simon Pepping wrote:
> > On Wed, Oct 05, 2005 at 09:54:17AM +0200, Jeremias Maerki wrote:
> > > On 05.10.2005 09:07:36 Finn Bock wrote:
> > > > So for inlines we get
> > > >
> > > > <fo:block>xxx xx xxx xx xxx x xxx xxxx <fo:inline
> > > > space-start="nn">iii i iii iii ii iii iiii iii iiii i ii iiiii
> > > > ii</fo:inline> xxx xxx xxxx xxx xxxx xxx xxx</fo:block>
> > > >
> > > > xxx xx xxx xx xxx x
> > > > xxx xxxx    iii i
> > > >     iii iii ii iii
> > > >     iiii iii iiii i
> > > >     ii iiiii ii xxx
> > > > xxx xxxx xxx xxxx
> > > > xxx xxx
> > > >
> > > > where a retained space-start is applied to each inline area,
> > > > not just the first one generated?
> > >
> > > Unexpected for inlines maybe, yes, but not necessarily for the
> > > b-p-direction and it's what the spec says IMO.
> >
> > I found this unexpected too. But I have realized that it is only
> > true if the conditionality is 'retain'. If it is 'discard', which
> > is the default, you only get the space where an inline area starts
> > inside a line, which is usually only the first area.
> >
> > For block areas a similar situation exists. A space-before with the
> > default conditionality of 'discard' will generally only be present
> > on the first area, because almost always the other areas will start
> > a reference area. This is not true for a block inside another block
> > which has a fence. In general the parent block only has a fence for
> > its non-first areas if the border or padding has a conditionality
> > of 'retain'.
> >
> > In all cases the user has to do quite a lot to get a space-before
> > on non-first areas.
> >
> > > > My understanding is more in line with Simon.
> >
> > I felt like I had missed something obvious. I feel better now. :-)
> >
> > > > I would guess that the key sentence is also true if the space
> > > > is applied to only the first area.
> > >
> > > How so? The spec talks about spaces around the generated areas of
> > > an FO, not the space around an FO. Or take the first sentence in
> > > 7.11.2: "Specifies the minimum, optimum, and maximum values for
> > > the space before any areas generated by this formatting object
> > > and the conditionality and precedence of this space." I don't
> > > read any restriction to only the first and last generated area of
> > > an FO for spaces out of this.
> >
> > The phrase 'before the areas generated by this formatting object'
> > is certainly not unambiguous. I read it as 'before all areas', i.e.
> > only once.
>
> Hmm, you're right. It could be interpreted that way.
>
> > Now I am not sure anymore. The other phrase, 'before any areas
> > generated by this formatting object' is clearer, although I have
> > trouble precisely understanding the meaning of the word 'any'. I
> > presume it means the same as 'before each area', but why doesn't
> > the spec use that unambiguous phrase?
>
> WG knows.... :-)
>
> > Maybe this phrase in 4.2.2, 'Unless otherwise specified, the traits
> > of a formatting object are present on each of its generated areas,
> > and with the same value.', also indicates that the trait
> > 'space-before' is present with the same value on each area?
>
> Oh, thanks for finding that one again. I knew I've read that before
> but couldn't remember when I wrote my previous reply.
>
> > > Once again we probably hit a flaw in the spec. AltSoft repeats
> > > the space-before on every page, XEP does not. And no changes to
> > > the text in XSL 1.1 WD. :-(
> >
> > I am glad to see that we are not the only ones who have a problem
> > with this part, but it is worrysome at the same time.
>
> It's sad. My impression that XSL-FO is worse than HTML concerning
> interpretation differences gets stronger and stronger lately.
>
> > > I think we should start a Wiki page listing all these bloody
> > > flaws in the spec for everyone to see.
> >
> > That is a good idea. As an extra benefit, the Wiki allows users to
> > add their interpretations.
>
> I'll write up what we found so far on space-resolution tomorrow. We
> can then ask the WG for a comment. I want to get this and the first
> release off my table quickly.
>
>
> Jeremias Maerki

Re: The space resolution examples

[Jeremias Maerki <de...@jeremias-maerki.ch>]

On 05.10.2005 20:32:53 Simon Pepping wrote:
> On Wed, Oct 05, 2005 at 09:54:17AM +0200, Jeremias Maerki wrote:
> > 
> > On 05.10.2005 09:07:36 Finn Bock wrote:
> > > So for inlines we get
> > > 
> > > <fo:block>xxx xx xxx xx xxx x xxx xxxx <fo:inline space-start="nn">iii i 
> > > iii iii ii iii iiii iii iiii i ii iiiii ii</fo:inline> xxx xxx xxxx xxx 
> > > xxxx xxx xxx</fo:block>
> > > 
> > > xxx xx xxx xx xxx x
> > > xxx xxxx    iii i
> > >     iii iii ii iii
> > >     iiii iii iiii i
> > >     ii iiiii ii xxx
> > > xxx xxxx xxx xxxx
> > > xxx xxx
> > > 
> > > where a retained space-start is applied to each inline area, not just 
> > > the first one generated?
> > 
> > Unexpected for inlines maybe, yes, but not necessarily for the b-p-direction
> > and it's what the spec says IMO.
> 
> I found this unexpected too. But I have realized that it is only true
> if the conditionality is 'retain'. If it is 'discard', which is the
> default, you only get the space where an inline area starts inside a
> line, which is usually only the first area.
> 
> For block areas a similar situation exists. A space-before with the
> default conditionality of 'discard' will generally only be present on
> the first area, because almost always the other areas will start a
> reference area. This is not true for a block inside another block
> which has a fence. In general the parent block only has a fence for
> its non-first areas if the border or padding has a conditionality of
> 'retain'.
> 
> In all cases the user has to do quite a lot to get a space-before on
> non-first areas.
> 
> > > My understanding is more in line with Simon.
> 
> I felt like I had missed something obvious. I feel better now. :-)
>  
> > > I would guess that the key sentence is also true if the space is applied 
> > > to only the first area.
> > 
> > How so? The spec talks about spaces around the generated areas of an FO,
> > not the space around an FO. Or take the first sentence in 7.11.2:
> > "Specifies the minimum, optimum, and maximum values for the space before
> > any areas generated by this formatting object and the conditionality and
> > precedence of this space." I don't read any restriction to only the
> > first and last generated area of an FO for spaces out of this.
> 
> The phrase 'before the areas generated by this formatting object' is
> certainly not unambiguous. I read it as 'before all areas', i.e. only
> once.

Hmm, you're right. It could be interpreted that way.

> Now I am not sure anymore. The other phrase, 'before any areas
> generated by this formatting object' is clearer, although I have
> trouble precisely understanding the meaning of the word 'any'. I
> presume it means the same as 'before each area', but why doesn't the
> spec use that unambiguous phrase?

WG knows.... :-)

> Maybe this phrase in 4.2.2, 'Unless otherwise specified, the traits of
> a formatting object are present on each of its generated areas, and
> with the same value.', also indicates that the trait 'space-before' is
> present with the same value on each area?

Oh, thanks for finding that one again. I knew I've read that before but
couldn't remember when I wrote my previous reply.

> > Once again we probably hit a flaw in the spec. AltSoft repeats the
> > space-before on every page, XEP does not. And no changes to the text in
> > XSL 1.1 WD. :-(
> 
> I am glad to see that we are not the only ones who have a problem with
> this part, but it is worrysome at the same time.

It's sad. My impression that XSL-FO is worse than HTML concerning
interpretation differences gets stronger and stronger lately.

> > I think we should start a Wiki page listing all these bloody flaws in
> > the spec for everyone to see.
> 
> That is a good idea. As an extra benefit, the Wiki allows users to add
> their interpretations.

I'll write up what we found so far on space-resolution tomorrow. We can
then ask the WG for a comment. I want to get this and the first release
off my table quickly. 


Jeremias Maerki

Re: The space resolution examples

[Simon Pepping <sp...@leverkruid.nl>]

On Wed, Oct 05, 2005 at 09:54:17AM +0200, Jeremias Maerki wrote:
> 
> On 05.10.2005 09:07:36 Finn Bock wrote:
> > So for inlines we get
> > 
> > <fo:block>xxx xx xxx xx xxx x xxx xxxx <fo:inline space-start="nn">iii i 
> > iii iii ii iii iiii iii iiii i ii iiiii ii</fo:inline> xxx xxx xxxx xxx 
> > xxxx xxx xxx</fo:block>
> > 
> > xxx xx xxx xx xxx x
> > xxx xxxx    iii i
> >     iii iii ii iii
> >     iiii iii iiii i
> >     ii iiiii ii xxx
> > xxx xxxx xxx xxxx
> > xxx xxx
> > 
> > where a retained space-start is applied to each inline area, not just 
> > the first one generated?
> 
> Unexpected for inlines maybe, yes, but not necessarily for the b-p-direction
> and it's what the spec says IMO.

I found this unexpected too. But I have realized that it is only true
if the conditionality is 'retain'. If it is 'discard', which is the
default, you only get the space where an inline area starts inside a
line, which is usually only the first area.

For block areas a similar situation exists. A space-before with the
default conditionality of 'discard' will generally only be present on
the first area, because almost always the other areas will start a
reference area. This is not true for a block inside another block
which has a fence. In general the parent block only has a fence for
its non-first areas if the border or padding has a conditionality of
'retain'.

In all cases the user has to do quite a lot to get a space-before on
non-first areas.

> > My understanding is more in line with Simon.

I felt like I had missed something obvious. I feel better now. :-)
 
> > I would guess that the key sentence is also true if the space is applied 
> > to only the first area.
> 
> How so? The spec talks about spaces around the generated areas of an FO,
> not the space around an FO. Or take the first sentence in 7.11.2:
> "Specifies the minimum, optimum, and maximum values for the space before
> any areas generated by this formatting object and the conditionality and
> precedence of this space." I don't read any restriction to only the
> first and last generated area of an FO for spaces out of this.

The phrase 'before the areas generated by this formatting object' is
certainly not unambiguous. I read it as 'before all areas', i.e. only
once. Now I am not sure anymore. The other phrase, 'before any areas
generated by this formatting object' is clearer, although I have
trouble precisely understanding the meaning of the word 'any'. I
presume it means the same as 'before each area', but why doesn't the
spec use that unambiguous phrase?

Maybe this phrase in 4.2.2, 'Unless otherwise specified, the traits of
a formatting object are present on each of its generated areas, and
with the same value.', also indicates that the trait 'space-before' is
present with the same value on each area?

> Once again we probably hit a flaw in the spec. AltSoft repeats the
> space-before on every page, XEP does not. And no changes to the text in
> XSL 1.1 WD. :-(

I am glad to see that we are not the only ones who have a problem with
this part, but it is worrysome at the same time.
 
> I think we should start a Wiki page listing all these bloody flaws in
> the spec for everyone to see.

That is a good idea. As an extra benefit, the Wiki allows users to add
their interpretations.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl

Re: The space resolution examples

[Jeremias Maerki <de...@jeremias-maerki.ch>]

On 05.10.2005 09:07:36 Finn Bock wrote:
> [Simon]
> 
> >>In general, I have a different idea about the retain
> >>condition. Retained spaces do not appear between areas returned by the
> >>FO; all spaces appear before or after all areas returned by the
> >>FO. This is different from retained padding and borders.
> 
> [Jeremias]
> 
> > That's the part where I think you are wrong. 4.2.3 and 7.10.5 make it
> > clear IMO that space-before|-after are applied to every area generated
> > by an FO. The following sentence is the key: "Specifies the value of the
> > space-specifier for the space before the areas generated by this
> > formatting object." (Notice the "areas"!)
> 
> So for inlines we get
> 
> <fo:block>xxx xx xxx xx xxx x xxx xxxx <fo:inline space-start="nn">iii i 
> iii iii ii iii iiii iii iiii i ii iiiii ii</fo:inline> xxx xxx xxxx xxx 
> xxxx xxx xxx</fo:block>
> 
> xxx xx xxx xx xxx x
> xxx xxxx    iii i
>     iii iii ii iii
>     iiii iii iiii i
>     ii iiiii ii xxx
> xxx xxxx xxx xxxx
> xxx xxx
> 
> where a retained space-start is applied to each inline area, not just 
> the first one generated?

Unexpected for inlines maybe, yes, but not necessarily for the b-p-direction
and it's what the spec says IMO.

> My understanding is more in line with Simon.
> 
> I would guess that the key sentence is also true if the space is applied 
> to only the first area.

How so? The spec talks about spaces around the generated areas of an FO,
not the space around an FO. Or take the first sentence in 7.11.2:
"Specifies the minimum, optimum, and maximum values for the space before
any areas generated by this formatting object and the conditionality and
precedence of this space." I don't read any restriction to only the
first and last generated area of an FO for spaces out of this.

Once again we probably hit a flaw in the spec. AltSoft repeats the
space-before on every page, XEP does not. And no changes to the text in
XSL 1.1 WD. :-(

I think we should start a Wiki page listing all these bloody flaws in
the spec for everyone to see.

Jeremias Maerki

Re: The space resolution examples

[Finn Bock <bc...@worldonline.dk>]

[Simon]

>>In general, I have a different idea about the retain
>>condition. Retained spaces do not appear between areas returned by the
>>FO; all spaces appear before or after all areas returned by the
>>FO. This is different from retained padding and borders.

[Jeremias]

> That's the part where I think you are wrong. 4.2.3 and 7.10.5 make it
> clear IMO that space-before|-after are applied to every area generated
> by an FO. The following sentence is the key: "Specifies the value of the
> space-specifier for the space before the areas generated by this
> formatting object." (Notice the "areas"!)

So for inlines we get

<fo:block>xxx xx xxx xx xxx x xxx xxxx <fo:inline space-start="nn">iii i 
iii iii ii iii iiii iii iiii i ii iiiii ii</fo:inline> xxx xxx xxxx xxx 
xxxx xxx xxx</fo:block>

xxx xx xxx xx xxx x
xxx xxxx    iii i
    iii iii ii iii
    iiii iii iiii i
    ii iiiii ii xxx
xxx xxxx xxx xxxx
xxx xxx

where a retained space-start is applied to each inline area, not just 
the first one generated?

My understanding is more in line with Simon.

I would guess that the key sentence is also true if the space is applied 
to only the first area.

regards,
finn