> -----Original Message-----
> From: Peter B. West [mailto:[EMAIL PROTECTED]]
> Sent: December 9, 2002 8:56 AM
> 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

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.


To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to