> -----Original Message----- > From: Peter B. West [mailto:[EMAIL PROTECTED]] > Sent: December 9, 2002 8:56 AM > To: [EMAIL PROTECTED] > Subject: Re: Redesign issues > > > Keiron Liddle wrote: > > > > > > I still believe that it is useful to have the layout managers separate > > from the fo tree. There are a number of reasons that come to mind. It is > > possible to independantly change layout managers. Certain fo's aren't > > directly in the same hierarchy: markers, undefined table columns, table > > cells under table body. Then there are things like floats and footnotes > > that can gain from this. > > Keiron, > > I'm inclining in this direction myself, because I am interested in > isolating the layout/area tree functions as much as possible from the > raw information stream of the FO tree. I tend to view the FO tree as a > read-only data source for the layout. manaaged by the Fo objects.
The feeling I got from my prototype is that there is not much commonality. Markers - there is no logic here that has anything to do with layout, per se. The content goes into a static-content and hence does not influence page break decisions. The logic for handling markers can be confined to the document level. "root" is an FO - it is the document, so it is the FO that can handle this. Floats and footnotes - the float goes on a page or it doesn't. The footnote starts on page N and continues through N+x or it doesn't. What FO knows about pages? The "page-sequence"...that's the natural FO for handling float and footnote problems. OK, this is somewhat simplified; with floats it may come down to columns, and then it is the "region-body" that also needs to intercede. Tables I can't comment on. So there may be an argument here for independent layout managers. I think we could use layout managers when it is clear that there is a layout problem involving N FOs, such that those N FOs are not identical to the children of a higher FO. I see keeps as being the main occurrence of this. But even then, keeps are still related to logic that occurs in page-sequence and region-body and lines (3 entities, in other words), and the nature of that logic differs in all 3 situations, so is it worth abstracting out a keep manager? I don't know. Here's a common ground that I can agree on...pull the layout logic out, and put it in "managers". This is not going to hurt. But really, really cut down on the urge to re-use managers through an inheritance hierarchy. I think this is also Joerg's point. It obfuscates more than it helps. Arved --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
