Hi Keiron,

Here are a few comments on your new layoutmgr stuff (which is definitely
more advanced than mine in most ways) :

1. I can't figure out how/where you manage space-start, space-end,
border, padding, background etc (ie, any non-inherited properties) for
non leaf node inline FO, ie: fo:inline and fo:basic-link. As you said,
you're "flattening" the inline LM, so in fact, you're just adding the FO
children of the inline. I think that if these FO _must_ create real
inline areas if they have any non-inherited properties. If they don't
they are acting kind of like fo:wrapper, and in that case, I agree we
don't need a separate layout manager, because no area needs to be

For basic-link, I think it would also be easier if it created an inline
area containing its child areas even if it doesn't have any
non-ineritable layout type properites. We could hang the linking
information on that area (or areas, if it split across lines).

But if we make nested inline areas, then the space adjustment as written
in the LineLayoutManager won't work correctly, because it won't see the
nested spaces.

2. Lack of context information: I ended up adding a LayoutContext oject
to pass information down to the LM(s) generating the areas. This is to
handle things like space-specifiers which can accumulate from various
tree levels, and also to indicate when a LM is generating a break (or an
Area) which is first in its parent area. That can influence things like
conditional space and borders and padding. What's a pain with that stuff
is that it changes the IPD, so until we know where the area is going to
be placed, we don't know exactly how big it will be.

3. I'd like to avoid having to generate all the child LM before starting
to layout any given level. This would limit us to waiting for a whole
fo:flow to be done (unless we special case at that level). I think we
can find a way to "pull" on the layout managers and still keep the
flexibility you gain with the addLayoutManager(List) approach. I think
it could be done with some kind of Iterator. (OK, I'm on kind of an
Iterator fling recently, but they _are_ really handy. :-)


To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to