Re: [Bug 29025] New: - Document/LayoutStrategy consolidation

[Glen Mazza]

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

[Simon Pepping]

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