On Fri, Nov 19, 2004 at 06:22:35PM +0100, Luca Furini wrote:
> A block inside another block
> 
> <fo:block>Normal text <fo:block>inner block</fo:block> normal text.</fo:block>
> 
> creates 3 different paragraphs:
> - Normal text
> - inner block
> - normal text.
> and each paragraph's layout is unrelated to the other paragraphs' layout 
> (there are 3 LineLM).

The 'normal text' is not indented, which makes it a 'continuation paragraph'.
 
> 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:
> a) 3 different paragraphs too:
> - Normal text inline text 1
> - inner block
> - inline text 2 normal text.
> or
> b) a single paragraph with all the text:
> - Normal text inline text 1 inner block inline text 2 normal text.
> ???
> 
> I'd say a), but I'm not sure.
> If this were true, there should be 3 different LineLMs.

I would say so too. I think that is what the spec prescribes for
fo:block. The fo:block is positioned w.r.t. the current reference
area, not w.r.t. the containing fo:inline. That makes it very similar
to the first example.

I believe the above is in fact a common layout pattern. It describes a
displayed equation in the middle of a paragraph. The second example
adds some layout characteristics, like specifying a different color,
font size, etc.
 
> This is the LM tree at the moment:
> 
>                  BlockLM1
>                     |
>                  LineLM1
>                     |
>        -------------+-------------
>        |            |            |
>     TextLM      InlineLM      TextLM
> "Normal text"       |      "normal text."
>                     |
>        -------------+-------------
>        |            |            |
>     TextLM       BlockLM2     TextLM
> "inline text 1"     |     "inline text 2"
>                  LineLM2
>                     |
>                  TextLM
>               "inner block"
> 
> LineLM1 tries to have get elements from all its chidren, and fails.
> 
> But, even if it could be given the elements representing "inner block", it
> could layout them wrongly, because of the block properties: the inner
> block could have different alignment, borders, margins, indents, ....
> 
> So, the LM tree could be:
> 
>                             BlockLM1
>               ------------------+-----------------
>               |                 |                |
>            LineLM           BlockLM2          LineLM
>        ------+------            |           -----+-----
>        |           |            |           |         |
>     TextLM     InlineLM      LineLM     InlineLM    TextLM
> "Normal text"      |            |           |    "normal text."
>                    |            |           |
>                 TextLM       TextLM      TextLM
>        "inline text 1"   "inner block"   "inline text 2"
> 
> This modified tree can be "easily" obtained from the previous one:
> - the new BlockLM is created
> - if the LM which should add it to its children list is an InlineLevelLM
> or a LineLM, the new BlockLM is given to its parent, i.e. it will become a
> child of the nearest BlockLM ancestor
> - an instance of the LM which could not handle the new BlockLM (in the
> example, InlineLM son of LineLM) must be created in order to handle inline
> siblings of the inner fo:block.

The third LineLM is not easy to program. Moreover, it has to know the
requirement that it does not start with an indent.

I think the first hierarchy is preferable and can be made to handle
the situation as follows.

The LineLM needs to be able to deal with paragraphs and blocks.

InlineLM's getNextKnuthElements should signal the end of the paragraph
(same as forced linefeed?) if it encounters a block-area generating
child LM. The next call to it should call the child LM's
getNextBreakPoss method, and return the BPs for the lines in the
block. InlineLM's getNextKnuthElements would return KnuthElements and
BPs. How can these return types be mixed?

LineLM's getNextBreakPoss would collect the returned KnuthElements in
paragraphs, and determine the BPs in it. It would store the BPs
received from its children unmodified.

The inner block would create its own areas, with proper alignment,
borders, margins, indents, etc.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl

Reply via email to