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.


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

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.

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.

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.


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.


Vincent

Reply via email to