On Fri, Sep 24, 2004 at 05:00:45PM +0200, Jeremias Maerki wrote: > Chris, > > Those who currently work on layout, how do you choose your work area?
My interest in FOP's layout is mostly theoretical. I cannot get enthousiastic about todo lists, time schedules and time estimates. 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. 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. 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. 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. > One big problem I currently see is testing properly. We don't have a > good set of tests that we can simply run. The example document are all a > big mess demonstrating several features at once. Sometimes I don't even > understand how it should (!) look. Personally, I'd add one important, > high priority task to the list: (Finally) creating a good test/QS > environment along with several simple documents each training a single > feature. Attached to this task should/could be the Java2D renderer which > we can used to easily create comparable bitmaps. I don't believe in MD5 > checking of PDF at this stage. That may be good as soon as we're in the > maintenance phase again. I agree. When I make a change to the layout system that might have far-ranging bad effects if I miss something, I try to convince myself with extensive logging. Good tests would be more satisfactory. Unfortunately, I do not yet know anything about unit testing, so I cannot write such tests. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
