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
