Karen,

Comments below.

Karen Lease wrote:

>Arved, Keiron et. al.
>
>I guess logically it's true that the blocks nested in inlines should be
>wrapped in inline areas, but it makes me nervous :-)
>At least they cause line breaks, that much seems sure. I still think
>that we should put pressure on the spec editors to either get rid of
>structure or clarify it in the next version (ha, ha). If people need
>blocks in inlines, they have inline-container.
>
>In fact, I'd like to think that the possibility of including block-level
>FOs in inline-level FOs is purely for convenience or "semantic nesting"
>and should not really affect the area tree, except to cause line breaks
>before and after the block areas.
>
>The most legitimate use I can see for this kind of semantic nesting is
>basic-link, because it could spread the link semantics over several
>areas; kind of a link-wrapper.
>
>-------------
>
>For the record, I disagree with Arved's reading of Line-Building. I read
>4.7.2, point 5 as saying that a block area generated by an fo:block can
>contain a mixture of block areas and line areas.
>
Agreed. In fact, it seems to me that the line-area is a pseudo-block 
designed to maintain the condition that the all of the children of an 
area must be of the same type, in the circumstance where there will 
clearly be block children of an fo:block, and to allow for simple block 
stacking in the BPDir. There is no need to wrap block areas in a line-area.

>Also, if we look at 4.7.3 (inline-building), I find it curious that it
>starts by saying TWICE that an inline FO places inline areas and anchor
>inline areas returned by its child FOs in inline areas which it
>generates, and then suddenly throws a block-area into the condition
>described in point 1. Looks more like a hasty copy/paste from the list
>for Line-building!
>
It's not just curious, it's contradictory. I have come around to Arved 
way of thinking on the behaviour of blocks in inline-areas, but the only 
way that I can see to do it is to change the relevant part of 4.7.3 to read:

An inline-level formatting object F which constructs one or more 
inline-areas does so by placing normal inline-areas *and/or normal block 
areas* and/or anchor inline-areas returned to F by its child formatting 
objects as children of inline-areas which it generates.

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 will be guaranteed by the partitioning 
arrangements of 4.7.3. The difference from 4.7.2 will be that these 
blocks will be wrapped in an inline-area generated by the fo:inline, 
which will in turn be wrapped in a line-area, exactly as per Arved's 
diagram.

However, as far as I can tell, this last level of wrapping is done by 
the parent fo:block in the process of laying out the inline-areas that 
are being returned by the the fo:inline. The decision to return a 
separate inline-area wrapping a block-area is made entirely by the 
fo:inline (or fo:basic-link). By the time the block gets to the parent 
block for layout, it is an inline area, and the only reason it is laid 
out in its own line-area is the constraint (from 6.6.7 fo-inline) that 
"no area may have more than one normal child area returned by the same 
fo:inline formatting object." The same constraint applies to fo:basic-link.

This leaves a question about where hyphenation is decided. In 4.7.2 
point 5, there is a discussion about glyph substitution, insertion and 
deletion which seems to assume that the sequences of inline-areas being 
built into line-areas are in fact fo:characters. The corresponding 
sequences bubbling up from fo:inline and fo:basic-link are already 
wrapped as integral inline-areas and presented as a fait accompli to the 
parent line-builder.

The fo:inline/fo:basic-link fo must obviously receive IPDim and BPDim 
information in order to present sane integral inline-areas to its 
parent, and to allow for the layout of nested fo:blocks. (This is pure 
hierarchical galley stuff.) In any case, there should be a correspondent 
in 4.7.3 to the discussion of substitution, insertion and deletion in 
4.7.2, just to make it clear what the responsibilities of the 
inline-builder are. That's if I have this right, this time. What do you 
think?

>As Keiron says, if the spec writers had been clearer, we wouldn't have
>to spend hours chasing our tails like this!
>
Or, alternatively, if they would clarify these questions in a timely manner.


Peter


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

Reply via email to