DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=29486>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=29486 Consolidate page generation code into FOTreeHandler Summary: Consolidate page generation code into FOTreeHandler Product: Fop Version: 1.0dev Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: page-master/layout AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Team, The following patch removes the event-driven messaging between fo.FOTreeHandler and apps.Document (used to activate the layout of each page sequence) and instead consolidates the formatPageSequence() activation into fo.FOTreeHandler. In effect, the business logic to start the layout process for each fo:page-sequence is consolidated from 5 classes (Driver, Document, FOTreeHandler, fo.FOTreeListener, fo.FOTreeEvent) back into one (fo.FOTreeHandler). This change is nothing new--it is closely similar in functionality to the former LayoutMgr.LayoutHandler , that we maintained through August of last year. (It is this class that became FOTreeHandler once this functionality was taken out.)  http://cvs.apache.org/viewcvs.cgi/xml- fop/src/java/org/apache/fop/layoutmgr/Attic/LayoutHandler.java?rev=1.5&view=auto With this change, two classes will be dropped: fo.FOTreeListener and fo.FOTreeEvent, two simplified (Driver and Document), and even the class retaining the logic (FOTreeHandler) will not be much larger, because all the event messaging logic has been removed from it. Streamlining this code will also aid in better comprehension of the process, hopefully making the code less intimidating/more attractive for others to work with. Will apply unless too much grief over the next couple of days! Thanks, Glen