Well, Finn's proposal is certainly looking nicer with
the new LM classes, as it would have far less layout
logic it would need to contain. If we can get it down
to one file, resembling our FOElementMapping class,
nothing but makers and devoid of layout logic, that
would be OK with me. Not my
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.
Right now I just have to replace AddLMVisitor (and the XXXLayoutManager
classes). As far as I understand your proposal, I would have to
--- Finn Bock [EMAIL PROTECTED] 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.
I have just noticed another issue. For perhaps 5-10
of the FO's, there actually *was* a lot of
layout-specific code within the FO's that probably
shouldn't have been there. Mostly this was because of
the use of anonymous subclasses. (See [1] for an
example of what Victor was able to
[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
Glen Mazza wrote:
Team,
While I'm implementing the validateChildNode()
methods, I would also like to work on removing the
AddLMVisitor visitor pattern[1], and revert to our
previous method of having the FO's themselves setup
the LayoutManagers via addLayoutManager(). (See here
[2][3][4] for
I still prefer my solution. Yours seems to be making
things more complex (i.e., replacing one class with 29
others by my count) rather than simpler. (Don't
forget, not everybody has an IQ as high as yours--some
of us need fewer moving parts to be productive! ;)
Please review the thread again
Glen Mazza wrote:
Well, the number of patches and enhancements made to
layout/rendering has only been about 2-3 per month in
the 12 months that we've had AddLMVisitor. FOP won't
finish at that rate, and that *will* affect the users.
I agree that FOP wont finish at its current rate of development!
--- Chris Bowditch [EMAIL PROTECTED] wrote:
Its the
getNextBreakPoss/addAreas methods in TextLM and
LineLM that are scarey.
Yes, that code is very complex (I wasn't able to fix a
problem with the space-after property despite much
effort), and I'm not sure there's anything that can be
done
On Tue, Aug 03, 2004 at 04:45:58AM -0700, Glen Mazza wrote:
--- Chris Bowditch [EMAIL PROTECTED] wrote:
Its the
getNextBreakPoss/addAreas methods in TextLM and
LineLM that are scarey.
Yes, that code is very complex (I wasn't able to fix a
problem with the space-after property
Victor Mote wrote:
J.Pietschmann wrote:
Well, the real stakeholders (aka users) are probably more
interested in working footnotes, or multi-column layout.
I don't understand. More interested in working footnotes or multi-column
layout than what? Is removing AddLMVisitor an advancement in
Well, the number of patches and enhancements made to
layout/rendering has only been about 2-3 per month in
the 12 months that we've had AddLMVisitor. FOP won't
finish at that rate, and that *will* affect the users.
In the 24 months preceding that change (i.e., the
original design I'm
I would rather remain silent in this acrimonious debate, but I suppose
that would not help.
I am in favour of a modular view of FOP:
- input specification
- layout
- rendering
I am in favour of reusability of the components. It would be good if
the layout engine could be applied to different
Victor Mote wrote:
I don't understand. More interested in working footnotes or multi-column
layout than what? Is removing AddLMVisitor an advancement in getting
footnotes or multi-column layout working better? Are you reminding us of
your neutrality on modularity? Or are you saying that this kind
Glen Mazza wrote:
While I'm implementing the validateChildNode() methods, I
would also like to work on removing the AddLMVisitor visitor
pattern[1], and revert to our previous method of having the
FO's themselves setup the LayoutManagers via
addLayoutManager(). (See here [2][3][4] for
Victor Mote wrote:
I mention it only to point out the *real* issue in case any
real FOP stakeholders are interested.
Well, the real stakeholders (aka users) are probably more
interested in working footnotes, or multi-column layout.
J.Pietschmann
J.Pietschmann wrote:
Well, the real stakeholders (aka users) are probably more
interested in working footnotes, or multi-column layout.
I don't understand. More interested in working footnotes or multi-column
layout than what? Is removing AddLMVisitor an advancement in getting
footnotes or
Team,
While I'm implementing the validateChildNode()
methods, I would also like to work on removing the
AddLMVisitor visitor pattern[1], and revert to our
previous method of having the FO's themselves setup
the LayoutManagers via addLayoutManager(). (See here
[2][3][4] for examples of the
18 matches
Mail list logo
