On 25.07.2006 18:59:00 Vincent Hennebert wrote:
> > DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUGĀ·
> > RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
> > <http://issues.apache.org/bugzilla/show_bug.cgi?id=39777>.
> > ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED ANDĀ·
> > INSERTED IN THE BUG DATABASE.
> > 
> > http://issues.apache.org/bugzilla/show_bug.cgi?id=39777
> > 
> > 
> > 
> > 
> > 
> > ------- Additional Comments From [EMAIL PROTECTED]  2006-07-23 19:47 -------
> > I finally had a chance to take a first look. What I've seen so far looks 
> > pretty
> > nice. A first simple test behaved as would be expected. Making a 
> > before-float
> > too big to fit on a page (although there are break points inside the 
> > content)
> > results in an OutOfMemoryError (probably due to an infinite loop).
> > 
> > It would be good if you would write a set of test cases for before-floats as
> > your next task. This is to document what works and what doesn't and to give 
> > you
> > and us more confidence when doing further chances in the code.
> 
> Testcases should be ready tomorrow.

Saw them, thanks a lot! I'll take a look tomorrow afternoon or Saturday.

> 
> > Finally, would you compile a list of classes you propose to move into the
> > "breaking" package? The idea itself is worth investigating since the 
> > layoutmgr
> > package has already grown rather big again.
> 
> On a general matter, I would put in the breaking subpackage all of the
> classes from layoutmgr and its subpackages which are related to the
> Knuth approach: the algorithm as well as the various Knuth elements. A
> quick look gave me the following classes:
> 
> AbstractBreaker
> BalancingColumnBreakingAlgorithm
> BreakingAlgorithm
> BlockKnuthSequence
> InlineKnuthSequence
> KnuthBlockBox
> KnuthBox
> KnuthElement
> KnuthGlue
> KnuthPenalty
> KnuthPossPosIter
> KnuthSequence
> PageBreakingAlgorithm
> inline.KnuthInlineBox

Ok, that's only strictly the pure Knuth stuff. There are a few other
classes we could talk about relocating, too. I'll try to categorize:

Element List Base class:
ListElement (superclass for KnuthElement and UnresolvedListElement)

"Unresolved" stuff:
SpaceResolver
UnresolvedListElement and subclasses

Utilities:
ElementList*.java
AreaAdditionUtil
LMiter
MinOptMaxUtil
TraitSetter

block-level LMs:
BlockLayoutManager
BlockContainerLayoutManager

"outer"-level LMs:
Flow-, StaticContent-, PageSequence-LM

LM-Infrastructure:
the rest

Maybe some of those classes could also be moved to some new subpackages
to clean the whole thing up a little more.

> This will probably create many access problems (with currently
> package-private members). But this will be an opportunity to clean up
> the whole thing a bit, I think.

Too much package-private access is bad anyway and is often done in order
to avoid writing accessor methods. So I guess this will be a good thing.

> In a second step there is also a number of inner classes which might be
> extracted and transformed into a top-level class of the new breaking
> subpackage. I'm mainly thinking of
> inline.LineLayoutManager.LineBreakingAlgorithm. I guess there are
> reasons why they currently are inner classes, but it may be conceptually
> better anyway to separate them from their surrounding class. This would
> have to be studied more deeply.

Yep, LineLayoutManager could probably do with some slimming down, too.

> As for when to apply the change, we may probably wait for the
> integration of Simon's work. I created the package just because I had a
> new class to put in it and thought that I might as well directly put it
> in the right package.

I agree. No good throwing unnecessary stones in Simon's path. But, Simon,
do you have an idea when you'll be ready?

> 
> So, WDYT?
> 
> 
> > What we need to decide now is whether to put the changes in a branch until 
> > they
> > stabilize or if we put it in Trunk. I'd prefer a branch for now so in case I
> > have time to finish the work on 0.93, we don't have any problems from this 
> > end.
> 
> A branch would be fine I think, as this would allow me to submit more
> gradual patches.

Good. I'll do that, then. ASAP. Damn busy week. And hot here. Tonight
was the first thunderstorm in many days of pure sunshine.

Sorry, I'm not more responsive this week.

Jeremias Maerki

Reply via email to