I agree with you (except for the last statment about one line).
I found this statement interesting: 6.6.7. fo:inline "An fo:inline that is a child of an fo:footnote may not have block-level children. An fo:inline that is a descendant of an fo:leader or of the fo:inline child of an fo:footnote may not have block-level children, unless it has a nearer ancestor that is an fo:inline-container." It suggests that what you are saying is correct and that block-level elements create a block area outside the immediate line area. So to have a block area inside a line area you must use the inline-container, a block is never automatically embedded. Also in this section, reading between the lines (it's amazing how they manage to contradict themselves in such a short section) 4.7.3. Inline-building An inline fo element with a block element as a child will create inline areas and return the block area. It will create a single inline area that can fit consecutive child inline areas on a single line. So the child inline areas are put into parent inline areas that are separated by line breaks and block areas. So Karen's approach is looking better. I really wish this spec would say relevant things in the right places and mention how everything is handled rather than being so vague. On 2002.05.01 04:00 Arved Sandstrom wrote: > Discussion follows below. > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf > Of > > Karen Lease > > Sent: April 29, 2002 5:39 PM > > To: [EMAIL PROTECTED] > > Subject: [REDESIGN] Line layout manager discussion > > > > Keiron Liddle wrote: > > > So why flatten the inline layout managers? > > > If we have an example like this: > > > > > > <block>Some text <basic-link>a paragraph of text<block>with a > > > block</block>and more text</basic-link> and <inline > > background="blue">blue > > > background<inline color="green"> green text <block>a block</block> > more > > > green</inline></inline></block> > > > > > > The basic link produces/returns both inline areas and a block > > area, so it > > > is not possible to say that the basic-link element or its layout > manager > > > would produce inline areas. So how should this be handled. If it is > > > flattened things are easier. The layout manager can then keep range > > > information like: starts link, ends link. > > I think this FO snippet is sufficiently complex as to be a good > Gedankenexperiment. I prepared a PNG which illustrates the area tree as > _I_ > interpret the spec applying to this FO. > > You'll have to view the image in colour. I have taken liberties with WS, > border colours, spaces, padding etc etc. I threw in one page break to > make > things interesting. Also, I have shown runs of texts as combined inlines, > where we know in fact that they are really containers for a bunch of > glyph > areas. > > Here's some of the main principles I am keeping in mind: > > 1. An area must have its child areas all of the same type (inline or > block); > 2. No area may have more than one normal block area returned by the same > fo:block; > 3. No area may have more than one normal inline area returned by the same > inline (fo:inline, fo:basic-link); > 4. A block generates normal block areas. If a child FO returns a block > area > this becomes a direct child of one of those block areas. If a child > returns > a sequence of inline areas, these become children of line areas which are > in > turn children of a normal block area; > 5. An inline generates normal inline areas. Each such may contain a > sequence > of inline areas or a single block area. > > Absolutely nobody else is going to agree 100% with my interpretation, but > I > think if we can hash this out it will allow us to really move forward > with > confidence. > > a) There are no block-level children of the top block, only inlines, so > we > know that the one or more block areas generated by the top-level block > are > going to contain line areas. Because of the page break there are 2 normal > block areas generated by the top-level block; > > b) "some text" is simple - the inline goes neatly into the first line > area > as its first child; > > c) Now we hit the basic link. This generates one or more normal inlines, > which are outlined in orange. The "a paragraph of text" is the first > inline > child of the first normal inline area generated by the basic-link; > > d) we hit the nested block. OK, this is where the anguish starts. :-) It > produces at least one normal block area, by definition. I have given this > a > pale green background. This _cannot_ occupy the first normal inline area > generated by the basic-link, because that already contains an inline area > (rule 1). So it must be in a second normal inline area generated by the > basic-link. By rule 3, the first line area may not contain 2 areas > generated > by the same inline, so that's why we terminate line aea 1 and start > another; > > e) In the second line area (outlined in dark blue), we have the second > normal inline area generated by the basic-link, outlined in orange. This > contains a single block area generated by the nested block (rule 5). In > order for the block area to handle the contained text ("with a block") it > must itself have a line area with inline children (one or more - I've > shown > one); > > f) we encounter "and more text". The same argument applies as in 'd' - > the > second inline area generated by the basic link cannot accept the inline > area > this text results in because it already contains a block area. So, a > third > inline area gets generated by the basic link, and by rule 3, this results > yet again in another line area; > > g) the third line area, now graced by the presence of the last normal > inline > generated by the basic-link (and its children), is able to handle more > line > areas, and so "and" and ""blue background" and "green text" certainly are > allowed. I chose to insert a line break after the "green". I hope the > colours help distinguish what is what - the inline child of the top-level > block ends up creating 4 normal inline area which have blue backgrounds; > > h) the doubly-nested inline produces inline areas that in fact have a > transparent background and so everything should be blue, but I thought > this > would lack clarity. The normal inline areas produced by the doubly-nested > inline have a thicker brown border. The same argument applies to the > block > which is nested in _this_ inline; the combination of rules 1 and 3 > require > different line areas. Again, the normal block area generated by the > doubly-nested block has a pale green background; > > _If_ there were blocks nested inside the top-level block these would > produce > normal block areas that are single children of normal block areas > produced > by the top-level block. My reading of Line-Building is that normal block > areas generated by a fo:block have either _single_ block areas _or_ one > or > more line areas as children, not a mixture. > > Final comment: it is the close intermingling of inlines and blocks in > this > example that causes so much line breaking. Clearly each of the 2 nested > blocks could be wrapped in inlines (fo:inline or whatever), and as a > result > everything in the example, in theory, could be in _one_ line area. > > Anyhow, please critique away. :-) > > Regards, > Arved --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
