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
