On 28.05.2005 06:46:59 Glen Mazza wrote: > Jeremias, perhaps Luca: > > Is there a reason why we maintain separate getNextKnuthElement() methods > within both an LayoutManager and its inner AbstractBreaker?
Looking at the code I think there is. They both have different responsibilities. Ok, BlockContainerBreaker has the same gNKE() as StaticContentBreaker. If you want to consolidate these two, why not. And: it works, why change it now? > Can they be > consolidated into LayoutManager and we call > getTopLevelLM().getNextKnuthElement() instead within the breaker code? I don't see how this is possible. > 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. > -- 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. Jeremias Maerki
