xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Victor Mote" <...@outfitr.com>
Subject RE: How layout works
Date Sun, 27 Apr 2003 07:10:17 GMT
J.Pietschmann wrote:

> it might be interesting to write up again how the layout core works
> in the old and in the new code.

I'm actually pretty deep into sorting out & restructuring the design
documentation for the new code. Thank you, thank you, thank you for the
write up here. I will weave it in to the existing doc, hopefully over the
next two days. We don't have a place to document the maintenance branch
layout design, but I'll create one if you think it will help.

I have started (in an article originally written by Arved) a project of
documenting in side-by-side columns (for the old and new code) some of the
key control points in the code:
This was started in an attempt to help developers quickly see what class
they might want to put a breakpoint in to see what is going on. As you can
see, it hasn't ventured into the Layout section yet :-). Please feel free to
add to it.

> My approach would be
> 1. get rid of all the iterators and move the functionality to the
>     layout managers because layout managers currently store many
>     of the same info anyway.
> 2. get rid of position objects and fold their data into break possiblities
> 3. make a proper hierarchy of break possibility objects
> 4. move stacking info to the layout context and make proper snapshots.
> 5. eventually get rid of the layout managers which correspond 1-to-1
>     to FOs and move the functionality back to the FOs.
> This is however not a small task, and I'm reluctant to start
> partly because
> inquiries to Keiron and Karen for rationales of the current design didn't
> result in anything, not even a statement like "It looked good"
> Also IDs, markers and out-of-line areas will need some more attention,
> the mapping from IDs to pages/areas for example should be stored in either
> athe next break possiblity or a layout context snapshot.
> Comments?

I'm not totally up to speed here yet, but here are my initial thoughts:
The first three all sound right. On #4, I may not be understanding what you
are saying, but I am not sure that we need snapshots at all. More on this

On #5, I have just recently decided that I liked the idea of the layout
managers totally separate from the FO Tree (after originally not liking it).
I'd like for layout to be pluggable, and keeping the LMs separate would seem
to facilitate that. Don't like FOP's layout? Drop in your own. I really
would like for the interface between FO & LM to be merely the passing of the
page-sequence FO to a page-sequence LM (which I don't think currently
exists). (It is pretty close to that now -- for some reason the Area Tree is
created first & passed with the FO). Actually, maybe what should happen is
that control goes back to the RenderContext, which either fires up a
StructureRenderer or a page-sequence LM. Once the page-sequence FO tree is
created & "refined", the only processing that the FO classes should do is
tree traversal, based on requests from the page-sequence LM ("Send me more
data if there is any!"). I think Peter has done some work on making the FO
Tree a first-class tree. FO Tree & Area Tree are data-oriented classes, LMs
are process-oriented. For saving memory, I am intrigued with the idea of
having the Area Tree keep track only of its parent FO, and pointers into its
content, i.e. an offset & size (text not existing in Area Tree, only
pointers to text in FO tree). The FO tree is the model, the Area Tree the
view, and the LMs the controller. Sometimes when I say things like this, I
find out later on that it is already so. If so, I apologize. I will readily
admit that I am still confused by a lot of what I see when stepping through
the code.

I read somewhere that Peter Karow (I think) was trying to extrapolate TeX's
paragraph-oriented line-breaking algorithm to a scheme that would optimize
layout for a chapter (page-sequence to us). Until talked out of it, I have
tentatively adopted this as my opinion of the "right" approach. Knuth has
laid out the theory, algorithms, and implementation in such detail on the
line-breaking logic, that it seems (to my optimistic mind) for the other to
be in reach as well. One possible result is that we may only need two LMs,
one for positioning text within rectangles and one for stacking rectangles
on pages. The first is basically the TeX paragraph-oriented line-breaking
scheme. The second would be the extrapolation to the page-sequence level
(which I think might do away with the need for snapshots).

I think this concept ties in with the Break Possibility idea. However, our
design doc still says that we are trying to send pages to the Renderer ASAP.
I think eventually this needs to be configurable, so that people can pick a
spot on the speed vs. quality continuum, and on the size-of-document vs.
speed continuum (i.e. a big document that needs high quality will have a
higher probability of needing to be serialized along the way).

My efforts over the past month have been oriented toward getting our doc
normalized & reorganized. The result will, I think, be smaller than the
preexisting doc, but without losing any content. We can then add to it as we
resolve some of these issues. Rhett suggested using a wiki, which is fine
for the discussion phase, but we eventually want to finalize the wiki & move
it into our design doc as issues are resolved. (We have a couple of wiki now
that need to be retired.)

I am somewhat reenergized by Joerg's work here. I am interested to know how
much interest there is from potential developers who follow this list in
getting more involved with coding, if we can get the layout design
documented & resolved better. I am thinking specifically of Rhett and Glenn,
but there may be others as well. Please speak up, tell us if you are
interested, and what you need. I think we would love to turn some serious
contributors into committers. I am glad to see Arved getting active again.
If we can get Peter's work rolled into the trunk, perhaps he could jump into
layout as well (??). We might have 6.05 to 8.05 developers here ready to
help Keiron.

My apologies for the long post.

Victor Mote

To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

View raw message