xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Mazza <grm7...@yahoo.com>
Subject Re: Switch from AddLMVisitor to FObj.addLayoutManager()
Date Fri, 06 Aug 2004 12:29:18 GMT
--- Finn Bock <bckfnn@worldonline.dk> wrote:
> Glen Mazza wrote:
> > I still prefer my solution.
> Ok, but please consider that it will then become
> somewhat more difficult 
> to add an alternative layout subsystem.

Layout subsystems are much rarer than people think, so
not that much a concern IMO.  Keyword here is
"somewhat more difficult"--it's not
insurmountable--and compared to the vast complexity of
creating a layout subsystem--almost noise level.  It
will be a few more headaches, but you'll have a better
LS in HEAD to base your code off of as a result.

> Right now I just have to replace AddLMVisitor (and
> the XXXLayoutManager 
> classes). As far as I understand your proposal, I
> would have to replace 
> FOElementMapping and subclass the FO tree classes in
> order to plug in a 
> new set of XXXLayoutManager classes.

Yes, but all this is not one-half percent the
complexity or difficulty of developing a brand new
alternative strategy to begin with (assuming it will
take at least 201 days, and one day for these
headaches).  I'm seeing the increase in patches to FOP
that will result in this change as a greater benefit*,
because (1) only the severe minority of FOP users
create their own layout strategies while the majority
benefits from a faster-created 1.0, and (2) more
patches give alternative LS people more and better
code for them to base their work on, and in some cases
may even remove the need to have an alternative LS at

*You are a good example, because if it's more
difficult for you to create an "alternative", you'll
be more likely to come back to FOP and start making
improvements to HEAD's layout strategy!  GOOD! (Please
do!)  I would rather you work on FOP than on a
competitor for it.


View raw message