Arved,
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
original example.
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
surrounding inline-areas."
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
line-breaking.
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.
Peter
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]
