Simon Pepping wrote:
<snip/>
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.
<snip/>
Chris
