[Glen Mazza]

I still prefer my solution.

Ok, but please consider that it will then become
somewhat more difficult to add an alternative layout subsystem.

[Glen Mazza]

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.

IMHO the closer integrated FO tree and LM tree classes is a worse starting point. Victor had the right intentions on this.

[...]. 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 seems to assume that the one default layout system in FOP can satisfy all requirements. I doubt that. The default layout system should be good but it shouldn't try solve everything perfectly IMO. Perhaps Jörg disagree <wink>.

*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.

My alternative layout subsystem isn't an alternative to FOP but an alternative way of implementing the getNextBreakPoss() code.

I do not yet know if anything will come of it but it looks quite promising. If it works, I'll post it as a patch for discussion.


Reply via email to