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

2004-09-13 Thread Luca Furini
Simon Pepping wrote:

 Still to be done:

 - Resolve the regressions mentioned above.

As concerns leader with use content, patch created and successfully tested.
The ContentLM calls getNextKnuthElements on his child InlineStackingLM, uses
the returned elements to calculate the pattern width and returns them to the
LeaderLM. The LeaderLM uses them when calling addAreas.

I also found a bug affecting leaders with leader-pattern = dots: the
TextArea with the dot (created in LeaderLM.getLeaderInlineArea) had width =
0; calling setWidth() fixes this problem.
There is still a little difference between a leader with leader-pattern =
dots and one with use-content and a single dot as content: the former is
placed a bit over the baseline, but I couldn't find the reason.

Note that using the fo file xml-fop/examples/fo/basic/leader.fo to test the
patch you won't see the leaders with leader-pattern = use-content, as they
don't have a width property and the default .opt value (12pt) is  than the
pattern width. Setting a larger width, or text-align-last = justify, makes
the leaders visible.

 - I support the idea to create an InlineLayoutManager interface, which
   extends LayoutManager.

Done, same patch (or maybe I should create a different one?). I also
removed the getWordSpaceIPD() method, as I find out that a constant value
works better: the LineLM and its child must use the same value, or the
result is not always correct.

 1.
 Can we be sure that U+A is always alone or the first item in a
 textArray; does this not depend on the Parser, how it calls the SAX
 characters method?

Right, it's better to handle the most general case.
The patch will fix this too.

I will try to fix the other points reported by Simon as soon as possible.

Regards
Luca





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