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
