Comments below. > -----Original Message----- > From: Peter B. West [mailto:[EMAIL PROTECTED]] > Sent: May 3, 2002 10:42 PM > To: [EMAIL PROTECTED] > Subject: Re: [REDESIGN] Line layout manager discussion > [ SNIP ] > From what I see here you are changing the shape of the tree. The > motivation seems to be to make it explicit that block areas contained > within an inline area must bubble up to become direct children of the > containing block area. I can't see that that is feasible, given the > basic design principle of the spec that the area tree follows the fo > tree. Specifically, by doing that, you lose what Karen called, iirc, > the semantic markers of the enclosing inline-area, e.g., fo:inline or > fo:basic-link. So how does that semantic information get to the > once-but-no-longer enclosed fo:block? It is possible to arrange the > transfer of such information to the block-area in the area tree, but > then the inheritance becomes a purely algorithmic thing, and the > structural link between the fo tree and the area tree is broken.
[ SNIP ] With respect to the second sentence of the above, I think we should be very clear at all times about exactly which area tree we are talking about - the conceptual area tree as described in the spec, or the real one constructed by Fop. Because in the conceptual tree block areas have a well-defined location and there is no "bubbling up" at all. Whereas in the real "tree" we can flatten completely and not have a tree at all, so we could have maximal "bubbling". As far as semantic information, are we talking about during layout or once the area is passed off for rendering? Because it seems to me that if we have managers then they can take care of retaining the semantic information (e.g. all areas generated or returned in this manager belong within a link). Once the areas are passed off to the renderer practically all the information needed to properly render any area can be expressed as traits on that area - one main exception is that areas need to know their nearest ancestor reference area for positioning. I am not discounting an area tree per se - with my xslfo-proc project I find an area structure (partial in my SAX implementation) to be the most convenient way of recording current layout information. That is, manager X needs to store certain information and it may as well use Area objects to do it. But I lean strongly towards a viewpoint where the areas have no knowledge of original semantics. Regards, Arved --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
