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 

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 

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]

Reply via email to