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

Reply via email to