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
> > 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]

Reply via email to