Hi all, I've been turning over some ideas about LayoutManagers, FOs and Areas and what's responsible for what. I've concentrated for now on the layout of inline stuff, for two reasons: a) we know the current area tree is incorrect at this level b) if we don't make Lines, the Block LayoutManager has nothing to work with. The scenario runs like this: A Block FO makes a Block Layout Manager (BLM). We probably want to have a factory mechanism for making Layout Managers, since that way we can use more or less elaborate ones. The Block FO then iterates over its children. It makes one Line LayoutManager for each sequence of inline-area producing children. (So an FO has to be able to tell what kind of areas it produces.) The Line LayoutManager (LLM) has as children the layout managers returned by each of the FO children of the Block FO. The most interesting kind of InlineLM is the TextLM which should have the word-breaking logic in it. There are TextLM implementations for different script systems, like typical Western and CJK. Once the hierarchy of LM is setup, the layout process starts. A BLM gets told (or asks for?) its inline-progression dimension (IPD). It then makes a BlockArea and gets areas from its child LM to fill the block areas. layoutManager.getArea(LengthRange inlineProgDim, LengthRange blockProgDim, LayoutInfo info) The layoutManager should return an area which fits in the inlineProgDim (minimum, optimum, maximum). For the LineLayoutManager, it will make a LineArea. It will then asks its child LM for areas which it will add to the LineArea. It manages the stacking in the inline direction, including space-specifier calculation. The LM for Inline FOs which contain other inline FOs basically acts the same as the LineAreaManager, but they make InlineAreas and not LineAreas and then propagate the getArea() to their kids. The TextFO is responsible for breaking at word breaks and/or legal hyphenation points. (Hyphenation logic should probably be a kind of plug-in to this and not be directly in the TextLM. One think I'm considering is the possibility of hyphenating runs of text which are actually part of two different TextFOs, possibly even at different tree levels.) The LayoutInfo is used to propagate information about layout state-- things like whether the current LM can make any more areas (whether all the content in its FO has yet been laid out), whether an inline area ends on a hyphen, whether an inline area ends on a breakpoint (space or other potential line-break character), etc). The created areas know their sizes, described as a rectangle relative to their baseline point for alignment purposes. Containing areas calculate their sizes based on what child areas they contain. -------------------------------------------------------------------- In short, most of the work that is currently done by the FOs is now done by the LayoutManagers. However, I think it's more than just moving code around. The LayoutManager class hierarchy can be different from the FO hierarchy. In particular, LM for objects which only manage other LM can be the same or very similar. Most of the work for inline layout should be in the TextLM. Obviously I'm eluding the floats for the moment, but this needs to be integrated quickly. The LM interface also has to know how to split existing areas and not just to make new ones. Suivant? (Next?) Regards, Karen --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]