Simon Pepping wrote:
My interest in FOP's layout is mostly theoretical. I cannot get
enthousiastic about todo lists, time schedules and time estimates.
Thats understandable.
I would like to see keep and break properties implemented. They are
the raison d'être of the new design. I do not think they can be
implemented with the current design, because there is no arbitrator of
the page length. The problem should be solved in a manner similar to
the way Luca solved the inline layout problem: All possible break
points should be returned to a high-level object, probably the Flow
LM. This then applies a certain algorithm, keeping lengths and keeps
and breaks into account, to determine the best break point. The
structure for this procedure must be added to the current design.
Oh I thought this was one of the key points that Keiron addressed when he
wrote the layout code in HEAD. Sounds like my estimate may be a bit longer then.
I am also interested in block stacking constraints. They exercise the
ability to relate the layout produced by one LM with the traits of the
areas produced by other LMs. Perhaps it can be done using the layout
context, perhaps one should navigate the LM tree to gather the
required data.
Finally I hope it will be possible to make the structure of the layout
module simpler. I believe it is the complexity of this module that has
hindered progress the most. With my recent change to LMIter I tried to
come closer to the semantics of a collection and an iterator, and make
it easier to create more iterator objects for the children of an LM
without disturbing the state of the one used in getNextBreakPoss. I
hope more such changes are possible and will make it easier to
understand the layout module.
Simplifying the LMIter objects is one way Joerg identified of making layout
easier to work on.
I do not know if this is a lot of work or not. To me it seems a
lot. Perhaps you may argue that this is not required for a 0.3
release. But to me it is rather essential to the new design. Without
it we might as well remain with the maintenance layout system.
keeps and breaks are essential for a 0.3 release. As you said yourself they
are the whole reason the redesign was started in the first place. I'm not sure
block stacking constraints are essential.
I understand that the new design for renderers has been more
successful, and may be a reason to want a release of the development
code.
This is not a good enough reason for a release.
Chris
