Re: DO NOT REPLY [Bug 29124] - New line breaking algorithm

2004-08-24 Thread Luca Furini

Simon Pepping wrote:

 Nested inline and other LMs: The output contains errors, see the
 comments in the text. The errors occur when hyphenation is set to
 true.

Fixed: there were errors in the method addALetterSpaceTo of LeafNodeLM and
InlineStackingLM.

I also found a bug in the LeafNodeLM.addAreas method, affecting HEAD too:
the area is added to the area tree (with parentLM.addChild(curArea))
*before* widthAdjustArea is called, so its width is not correctly added to
the inline parent width and the output sometimes shows overlapped text
(when there is another child of inline parent after the leader area).

 Justification: This is a test fo you submitted earlier. According to
 the text in the file the second block should be hyphenated; it is
 not. Should it still be hyphenated, or can this not be enforced with
 the Knuth algorithm and text-align=start?

I cannot find a hyphenate property in the fo file you attached, so I'm not
sure whether I understand what you mean.
Anyway, hyphenate = true means, according to the recommendation (7.9.4),
that hyphenation may be used in the line-breaking algorithm, not that it
*must* be used.
As hyphenation is time-expansive and bad-looking, I think it should be
used only if necessary.

 No breakpoints: An exception is thrown, at
 LineLayoutManager.getNextBreakPoss(LineLayoutManager.java:495). It
 occurs because breakpoints has size 0; the third call to
 findBreakingPoints also returned 0. This should not be possible; the
 algorithm should always return a breakpoint.

Right, I completely forgot to provide a fallback in case the algorithm
doesn't find a good set of breaking points.
I added a boolean argument called force to findBreakingPoints: if it is
true, and after the main loop there are no active nodes, the last
deactivated node is used to create LineBreakPositions.
There will zero or more good lines followed by a single line including
all the remaining content (this line will obviously get off the right
margin).

The method findBreakingPoints will be called no more than three times:
I) no hyphenation, adjustment ratios must be = 1
II) hyphenation (if allowed), or ratios up to 5
III) ratios up to 20, and if necessary force the creation of LineBreakPositions

 A few small remarks:

 Can you move the following log messages to trace log level:
 [DEBUG] AbstractLayoutManager - - Word to hyphenate: We

Done

 In TextLM, returning null for a forced LF is not an idea that I like,
 because it overloads the null return value. Cannot you return an
 special Knuth element for LF? Alternatively, you could return null and
 process the paragraph. The second paragraph would then be produced and
 processed later.

A preserved linefeed can be represented by a penalty item whose value is
-infinite: +inf means that there can't be a break here, -inf means that
there must be a break (as there can't be a better breakpoint).

Preserved linefeeds inside inlines are much more problematical than I
first thought, but they should work now: I had to add a List argument to
the applyChanges() and getChangedKnuthElements() methods, to tell an ISLM
which children it has to consider.

 InlineStackingLM.getNextKnuthElements: 'if (lc.startsNewArea())' no
 longer used?

I tried to preserve the existing code as much as possible, so I didn't
touch that if statement.
Maybe I removed some lines in the LineLM so that lc.startsNewArea is never
true?

Regards,
Luca




DO NOT REPLY [Bug 29124] - New line breaking algorithm

2004-08-24 Thread bugzilla
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=29124.
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=29124

New line breaking algorithm





--- Additional Comments From [EMAIL PROTECTED]  2004-08-24 15:24 ---
I'm going to attach still another version of the patch :-), corrected 
according to Simon's comments.

The new files (Knuth*.java) are unchanged, so I don't attach them.

Regards, 
Luca


DO NOT REPLY [Bug 29124] - New line breaking algorithm

2004-08-24 Thread bugzilla
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=29124.
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=29124

New line breaking algorithm





--- Additional Comments From [EMAIL PROTECTED]  2004-08-24 15:25 ---
Created an attachment (id=12518)
patch to existing files (sixth edition)


DO NOT REPLY [Bug 30816] - ClassCastException thrown in TableLayoutManager.getNextBreakPoss(LayoutContext)

2004-08-24 Thread bugzilla
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=30816.
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=30816

ClassCastException thrown in TableLayoutManager.getNextBreakPoss(LayoutContext)





--- Additional Comments From [EMAIL PROTECTED]  2004-08-24 19:09 ---
Arthur,

Thanks for reporting this problem. Can you attach the fo file that generates the
error?

Simon


DO NOT REPLY [Bug 30816] - ClassCastException thrown in TableLayoutManager.getNextBreakPoss(LayoutContext)

2004-08-24 Thread bugzilla
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=30816.
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=30816

ClassCastException thrown in TableLayoutManager.getNextBreakPoss(LayoutContext)





--- Additional Comments From [EMAIL PROTECTED]  2004-08-25 02:53 ---
Arthur,

Can you give us a minimal *FO* document, with no XSLT transformations necessary,
that will reproduce this problem?   Use Xalan if need be.

Thanks,
Glen