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
