Re: [Bug 29025] New: - Document/LayoutStrategy consolidation
Simon Pepping wrote: Note in this respect the comment in LayoutStrategy.java: /** Useful only for allowing subclasses of AddLMVisitor to be set by those extending FOP **/ right above private AddLMVisitor addLMVisitor = null; I think you should copy that comment to Document.java as well. Just added the comment, thanks. Now I'm back to (1) the space-before/space-after issues on both static-content and fo:flow, and to hopefully (2) add to Andreas' research on the table issue. I tried to run a report at work on 1.0 instead of 0.20.5 and had found five bugs--I fixed four of them, the spacing issues are the last, and then (at least for my report) 1.0 is as good as 0.20.5. Then, test my next report..., and the next, and the next, then finally...the Docbook fo stylesheet! Glen
Re: [Bug 29025] New: - Document/LayoutStrategy consolidation
On Sun, May 16, 2004 at 07:10:50PM -, [EMAIL PROTECTED] wrote: Team, The following patch incorporates the (rather simple) LayoutStrategy code into the apps.Document class, and does away with LayoutStrategy and LayoutManagerLS.java. Implementation of multiple layout strategies, should we ever be doing this, is still possible, and with roughly the same complexity, however by reimplementing and/or subclassing apps.Document instead. This simplifies the LayoutManager code and makes the tracing of Document creation a bit easier to follow, hopefully beneficial for other developers besides me. The motivation for this change is that currently I'm trying to implement space-before correctly in fo:static-content (as a digression, doesn't work on pages past the first, because I reset its value to zero for fo:flow, need to find a way to differentiate the layout between the two types) and some reduction of the number of dimensions of the source code makes it easier for me to understand the process. If I understand this correctly, this patch removes one user-configurable layer between Document and the LayoutManagers, viz. the LayoutStrategy. This means that AddLMVisitor becomes a direct child of Document instead of LayoutStrategy. I am not an opponent to such user-configurable layers. It allows users to combine parts of the application according to their own needs. OTOH, we are far from a situation where this would be useful, and the perspective of a user implementing another LayoutManagement is extremely unrealistic. I am therefore neither against nor in favour of the change; either way is OK with me. I have always felt that AddLMVisitor is another user-configurable layer between Document and LMs. That was a bit weird, and the proposed situation is more normal. Note in this respect the comment in LayoutStrategy.java: /** Useful only for allowing subclasses of AddLMVisitor to be set by those extending FOP **/ right above private AddLMVisitor addLMVisitor = null; I think you should copy that comment to Document.java as well. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
DO NOT REPLY [Bug 29025] New: - Document/LayoutStrategy consolidation
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=29025. 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=29025 Document/LayoutStrategy consolidation Summary: Document/LayoutStrategy consolidation 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 incorporates the (rather simple) LayoutStrategy code into the apps.Document class, and does away with LayoutStrategy and LayoutManagerLS.java. Implementation of multiple layout strategies, should we ever be doing this, is still possible, and with roughly the same complexity, however by reimplementing and/or subclassing apps.Document instead. This simplifies the LayoutManager code and makes the tracing of Document creation a bit easier to follow, hopefully beneficial for other developers besides me. The motivation for this change is that currently I'm trying to implement space-before correctly in fo:static-content (as a digression, doesn't work on pages past the first, because I reset its value to zero for fo:flow, need to find a way to differentiate the layout between the two types) and some reduction of the number of dimensions of the source code makes it easier for me to understand the process. Anyway, if no complaints I'll commit this in a couple of days. Thanks, Glen