On 17 Nov 2008, at 20:40, Simon Pepping wrote:

On Mon, Nov 17, 2008 at 06:39:58PM +0100, Andreas Delmelle wrote:
On 17 Nov 2008, at 12:36, Vincent Hennebert wrote:

Does anybody know why FOP Trunk completely screws up the rendering of the attached file? It works fine when removing the fo:inline element,
so
I guess this has something to do with that element. FOP 0.95 renders
the
file correctly, both with and without the fo:inline.

I cannot pinpoint which change would have triggered this, but running
some tests here, it seems hyphenation is also an influencing factor. If you disable it, the document renders fine. The problem is not restricted
to fo:inline. Using a fo:wrapper produces the same weird result...

I suspect it is related to some changes in TextLayoutManager (a lot has
changed in there compared to 0.95), so I'm going to look a bit deeper
(debug what happens with the element list during hyphenation), and will
let you know if I find anything.

Someone sent me a file which also shows problems with hyphenation:

<fo:block hyphenate="true"><fo:inline>Some text ending in a space and
a period .</fo:inline></fo:block>

If the text is longer than a line, parts of the text
disappear. Without hyphenation there is no problem. Maybe it is
related.

I was thinking so too (see related thread on fop-users@, earlier today).

The text does not even have to overflow a line to cause the effect. One word followed by a space and a period is enough to make the period disappear. Could also be remotely related to bug 38264. ( https://issues.apache.org/bugzilla/show_bug.cgi?id=38264 )

I've already been running some debug-sessions, and don't see anything immediately wrong about the generated Elements or the AreaInfos before and after applying hyphenation. The used hyphenation pattern obviously has an effect, because we have more or different hyphenation points...

One thing I noticed, that seems suspicious:
Is it normal if applyChanges() returned true for a TextLayoutManager, that getChangedKnuthElements() isn't called later for that instance? Doesn't that lead to wrong position-pointers?


Andreas

Reply via email to