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]
