Hi, The NIST test suite has no example of an fo:block within an fo:inline element. Neither does the XSL spec have an example. Apparently the construction is not very popular.
I have read through the XSL spec, sections 4.4. Block Areas, 4.5. Line Areas, 4.6. Inline Areas, and especially 4.7.2. Line building and 4.7.3. Inline building. See esp. items 1, 3, and 5 of the rules for the partitioning. I believe the following areas should be created: A block inside another block <fo:block>Normal text <fo:block>inner block</fo:block> normal text.</fo:block> creates: Block area -+-- Line area +-- Character areas | +-- Block area +-- possibly Line area etc. | +-- Line area +-- Character areas A block inside an inline inside a block <fo:block>Normal text <fo:inline background-color="lightgreen">inline text 1 <fo:block>inner block</fo:block> inline text 2</fo:inline> normal text.</fo:block> creates: Block area -+-- Line area +-- Character areas | +-- Inline area -- Character areas | +-- Line area +-- Inline area -- Block area +-- Line area etc. | +-- Line area +-- Inline area -- Character areas +-- Character areas The fo:inline creates three inline areas, one with the text 'inline text 1', one with the block area, and one with the text 'inline text 2'. The outer block arranges the inline areas from its PCDATA and those returned by its fo:inline child into lines. Note also that the inner block area behaves as a child of the inline area with respect to such traits as the border and the background traits. As a conclusion I believe InlineLM must be modified to handle the BPs returned by a block-area generating child. Perhaps it should wrap them in a Knuth Box of the appropriate width, or in a new class of Knuth Element, which LineLM would know that it should be placed on a line of its own. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl