On Wed, 2002-08-14 at 22:06, J.Pietschmann wrote:
> Keiron Liddle wrote:
> > - Add static areas to page
> > The static areas will need to be handled in a similar way to the flow
> > except the bpd is unlimited and it will need to reset and repeat for
> > each page.
> I looked at it. Is static content supposed to be handled
> by a FlowLayoutManager too? It seems a bit too specialized
> to a fo:flow to me.
I would think it would be another class but quite the same.
It does the same thing except it doesn't find breaks it just adds all
> I think I understand now why the design of HEAD is as
> it is now. I still think there are better possibilities,
> perhaps deriving classes representing FOs from layout
> manager classes, thereby avoiding communication between
> the objects representing FOs and the associated layout
I want A solution, the current one is the closest we have right now.
> Does anybody dare to apply an OO metric to HEAD? Deeply
> nested inheritance trees, lots of communications from
> everywhere to everywhere... I'd bet the complexity is
> just a notch below "for supergeniuses only", which would
> nicely fit the unusual long time it took me to grasp
> why *anything* is laid out at all.
I haven't noticed lots of communication everywhere to everywhere, most
of it is single direction or single purpose.
The layout context and break possibility make things a bit confusing.
The complexity of the layout means that a lot of this is necessary.
I don't think we should expect or even want people to understand
everything. In a way understanding the layout *is* understanding the
spec except it is done in a particular way.
> > except the bpd is unlimited
> You mean "limited", do you?
No for a static area all areas are placed into the static region. So
that the block progression dimension is unlimited. The clipping and
overflow determine what happens when rendering the things outside the
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]