You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Karen Lease <kl...@club-internet.fr> on 2001/09/20 23:43:02 UTC

[REDESIGN] Layout Manager ideas

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: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org