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
