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
complex_block.png
Description: PNG image
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
