You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by bu...@apache.org on 2004/05/16 21:10:50 UTC
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: fop-dev@xml.apache.org
ReportedBy: glenmazza@yahoo.com
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
Re: [Bug 29025] New: - Document/LayoutStrategy consolidation
Posted by Glen Mazza <gr...@yahoo.com>.
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
Posted by Simon Pepping <sp...@leverkruid.nl>.
On Sun, May 16, 2004 at 07:10:50PM -0000, bugzilla@apache.org 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