Hi Karen, Its seems that there are gotcha's no matter what direction we take. I will try to present the reasons behind the approach I am taking. I welcome your input and I will look at the code to see how your code works.
It seems we need a set of "tough cases" that we need to be able to handle to be confident of the correct approach. 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. Determining line breaks: <block>text on a hyphenated line with a col<inline color="red">our</inline>ed word</block> In this case the text layout manager cannot determine a break after "col", only the line layout manager can work out a suitable break point or hyphenation. (I don't know what your code does but this is why I simply get areas from the text layout manager) 1&2. This is the idea of the range properties. I can see how putting everything in a single inline area could be useful as long as other things are easily transparent. I was thinking of getting this information from the inline layout managers so that the line layout manager can deal with it appropriately. 3. Ideally the layout process should start as soon as the first block is ended (no matter how deep it is). So something like, when starting a block level element the layout manager is added to the parent, when a block level element is ended then the layout process starts and adds the areas from that block etc. How this will happen in practice I haven't really thought about. If the iterator can do that then we should use it. On 2002.04.29 00:16 Karen Lease wrote: > 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]
