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
