Again, I agree that, in the conceptual area tree described in the spec,
blocks embedded in inline-area generating FOs in the fo tree (e.g.,
fo:inline and fo:basic-link), themselves embedded in a parent fo:block,
do not bubble up to the same level as the parent fo:block. Going back
to your diagram, I am talking about the fo:block embedded in the
basic-link. I have attached another diagram describing a subset of your
Let me clarify what I meant by the term "bubble up" in the reply to Karen.
"Then what seems to me to be the *intention* that layout within
fo:inline and fo:basic-link proceed as though these wrappers were
layout-transparent, would be made clear. That is, blocks bubbling up
from below will be stacked in the BPDir without IPDir attachments from
This refers to the spec's conceptual area tree. It arises out of my
misapprehension that the nesting of fo:blocks within inline-area
generators would involve a nesting of the layout within the generated
inline-area. The fo:inline inline-area in the area tree would grow
within the bounds of the containing line-area and block area, but
limited by it.
It doesn't work that way, though, as we have all discussed. These block
areas "bubble-up", not in terms of their containment within the
appropriate set of line-area->inline-area->block-area, bu in terms of
their layout consequences. Apart from any layout-altering properties
defined on the containing inline-area generator, e.g.font or border
changes, the text and any nested blocks are treated for layout as though
they had occurred as direct children of the outer fo:block. That's what
the term "layout-transparent" means.
That, at least, is what I take the *intention* of the authors to be.
And that is why I want to see some clarification of the relationship
between 4.7.2 Line-building and 4.7.3 Inline-building. It seems to me
that the spec decrees that the initial text of the basic-link ("In
basic-link " in my example) is constructed into an inline-area by the
Inline-building process of 4.7.3. In order to do this, it has to know
about the constraints that it inherits from the already partially
constructed line-area which contains "Text in block ". It seems to me
that, conceptually at least, in the conceptual area tree model of the
spec, the inline-building process needs to take account of all of the
glyph substitution, insertion and deletion considerations that apply to
4.7.2, because it is now the responsibility of the inline-area generator
to generate a *single* inline-area to complete the pending line-area of
the parent. To do that, it will have to be able to do its own
Clarifying this is a matter of the coherence and consistency of the
spec. It is also important if you are tempted, as I am, by the idea of
mimicking this conceptual model and procedure in actual code.
All of the above may just mean that, while I thought I had been brought
around to your way of thinking on this aspect of the spec, I may still
be thinking about it very differently.
Arved Sandstrom wrote:
>My last post was motivated by one thing - the statement that a block area
>"bubbles up". Well, it does not, not in the conceptual area tree described
>in the XSL spec. As a result I thought it worth our time to ask for some
>specificity when the area tree being referred to is not immediately obvious.
>I agree with your sentiments, particularly the last sentence. As such I
>think it is very important to establish exactly what area tree we are
>talking about in any given context. In theory there are at least 2 - the XSL
>1.0 conceptual area tree, and the real "tree" (really, whatever structure we
>happen to use). There could be more.
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]