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 favo
On Thu, Aug 05, 2004 at 08:31:59PM -0700, Glen Mazza wrote:
> 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 fewe
--- Finn Bock <[EMAIL PROTECTED]> wrote:
>
> 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 p
[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'
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 remove--espe
--- 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 conce
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 r
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 to
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 exampl
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 pr
--- 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
d
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!
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 o
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 inpu
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 recommending
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 getting
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 m
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
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] f
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 previou
20 matches
Mail list logo
