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 

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.

PNG image

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to