Hi All,
What it boils down to seems to be if the inline fo returns the block
area or generates an inline area that contains the block area. If it
generates an inline area then it will set traits on that area (border,
background, link, padding etc.).
If that is the case why is a footnote inline not allowed to have a block
level child. Since this is effectively the same as using an
inline-container.
Here is another confusing statement, that makes sense for
inline-container.
4.6
"The dimensions of the content-rectangle for an inline-area without
children is computed as specified by the generating formatting object,
as are those of an inline-area with block-area children."
Does "computed as specified" mean specified on the fo or derived from
the context.
>From a practical viewpoint it makes sense to wrap the block in an inline
area with the traits and treat the block normally in layout terms but it
still feels uncomfortable. It also introduces a whole lot of other
questions about line height, padding etc.
Keiron.
On Mon, 2002-05-06 at 03:52, Peter B. West wrote:
> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
