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