Re: The space resolution examples
[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:blockxxx xx xxx xx xxx x xxx fo:inline space-start=nniii i
iii iii ii iii iii i ii i ii/fo:inline xxx xxx xxx
xxx xxx/fo:block
xxx xx xxx xx xxx x
xxx iii i
iii iii ii iii
iii i
ii i ii xxx
xxx xxx
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
Re: The space resolution examples
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:blockxxx xx xxx xx xxx x xxx fo:inline space-start=nniii i iii iii ii iii iii i ii i ii/fo:inline xxx xxx xxx xxx xxx/fo:block xxx xx xxx xx xxx x xxx iii i iii iii ii iii iii i ii i ii xxx xxx xxx 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
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:blockxxx xx xxx xx xxx x xxx fo:inline space-start=nniii i iii iii ii iii iii i ii i ii/fo:inline xxx xxx xxx xxx xxx/fo:block xxx xx xxx xx xxx x xxx iii i iii iii ii iii iii i ii i ii xxx xxx xxx 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
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:blockxxx xx xxx xx xxx x xxx fo:inline space-start=nniii i
iii iii ii iii iii i ii i ii/fo:inline xxx xxx xxx
xxx xxx/fo:block
xxx xx xxx xx xxx x
xxx iii i
iii iii ii iii
iii i
ii i ii xxx
xxx xxx
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
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:blockxxx xx xxx xx xxx x xxx fo:inline space-start=nniii i iii iii ii iii iii i ii i ii/fo:inline xxx xxx xxx xxx xxx/fo:block xxx xx xxx xx xxx x xxx iii i iii iii ii iii iii i ii i ii xxx xxx xxx 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
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
It could very well be that I got something wrong about spaces. Unfortunately, I don't have much time right now to dive into this, so it has to wait until next week. But we should probably start by analyzing the spec to see what the real behaviour should be. Please update the Wiki if you find the right references. Thanks and sorry for not immediately addressing it. 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. 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. * Example 0 IMHO it should be: Here we look at the case where a break happens before before break. * 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 * 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 * 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 * 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 * 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 * 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 Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl Jeremias Maerki
