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 created. 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. :-) Regards, Karen --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
