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
