Hi Luca, Thanks for the support!!! I am resurrecting this idea. I do think the insights gained will be considerable--and the resultant architecture will become more streamlined, rigorous, and more respected by the people that FOP needs to look good to.
I did 28 CVS commits on the Knuth branch--a couple needed reverting, but in general I'm happy with the before-and-after as well as the quality of email conversations it engendered. I wish to continue the work. But, yes, we can wait a (little!) bit on this and the simplification you mention below also sounds like a good idea. Regards, Glen ----- Original Message ----- From: "Luca Furini" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Wednesday, May 18, 2005 12:57 PM Subject: Re: Layout simplifications > Glen Mazza wrote: > > > [...] > > I think if we do this, it will allow for more simplifications and > > insights into the layout coding, and make it easier to understand. I > > don't think we can afford the duplication as-is--my experience so far > > with FOP is that simplifying engenders more simplifications, while lard > > ends up begetting more lard. > > It seems a good plan; maybe it would be better to wait a little time, so > that the code is more or less stabilized. > > As we are talking about code simplifications: at the moment there are > classes for the sequences of elements (KnuthSequence, extended by > Paragraph and BlockSequence) and for the breaking algorithms > (BreakingAlgorithm, PageBreakingAlgorithm, LineBreakingAlgorithm). > > The sequences and the algorithms are tightly coupled, and they share (or > duplicate) many parameters: what about having a class with both the > sequence of elements and its specific breaking method? > > Regards > Luca > > >
