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()?

Nothing.

If "nothing", 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
goal, too.


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?

Thanks,
Glen

Reply via email to