Jeremias Maerki wrote:
Three LM classes have these two "duplicate" methods: PSLM, SCLM, and
BlockContainerLayoutManager. SCLM and BCLM I cannot tell if they are
mergable--it looks doubtful to my eyes but I'm unsure, however PSLM's
two implementations look somewhat strange: for PSLM, what else would
activate PSLM.gNKE() other than its PageBreaker.gNKE()?
those two should be merged at least to PSLM's implementation to clarify
I don't think so. AbstractBreaker subclasses' responsibility is to
control the breaking process and thus initiate gNKE() calls on the right
LMs. The individual LM's are simply responsible to handle their own FOs.
Excellent! This is exactly what I'm looking for--with this
architecture, the LM's gNKE() are to handle getting the Knuth elements
for their FO's, while the Breaker gNKE() are to handle routing between
various LM's gNKE() methods. I hope to comment the code soon to make
that clarification so others are aware.
-- I'll happily do so if I'm correct here.
I bet. I can only say it again. My priorities are getting FOP into a
releasable state. You won't get a medal from my by gilding our code
right now. What FOP really needs right now is finally getting to an
initial developer release. I doesn't have to be perfect but it has to
show our users that the long waiting period was worth waiting for. I
strongly believe that once we have an initial release, people will start
coming back, trying it out and we will see more people contributing. I
really, really, really wish you would channel your energy towards this
My energies right now are only in understanding layout, and in finding
and making changes that will make it easier for others to understand it
as well. Users/Release dates, etc. are not my concern. I'll be doing
the same work before FOP's release that I will be doing after its release.
BTW, are we losing potential committers due to FOP 1.0 supporting JDK
1.3? We haven't heard much from Renaud since you asked him to maintain
some special 1.3-only graphics package that we otherwise wouldn't need
to have. I want to make sure we didn't lose him to a 1.4/1.5 project
because he couldn't afford to hurt his skill sets by working on 1.3. If
we did, IMO it would be better for the 1.3 users to stay on 0.20.5 so
the 1.4 users can have the benefits of new contributors' work in 1.0.
Your comment on channelling energy is what reminded me of this.
AntennaHouse is requiring 1.4.2+. So the time that we're spending on
that 1.3 graphics package they are presumably spending on speeding up
their SW for their (Windows, Linux, HP, Solaris) user base. Are they
doing a better job of channelling energy than we are? Are they doing a
better job of determining which users to concentrate on?