Hi Terry,
Terry Lurie wrote:
Hi, it occurred to me that the questions may be more related to dev
activity.
Using the new Batik 1.6 , flowRoot elements do not transcode to PDF
correctly.
Hmm, you are correct, very surprising.
The file batik-1.6/samples/tests/spec12/text/flowRegionBreak.svg also
highlights the problem.
Yes actually our standard rasterizer has the problem as well.
It seems that the text baseline gets set to the top of the PDF and that
the wrapping no longer works. That is, flowLine does not cause a new
line. You will be able to see the descending part of the 'j' at the top
left of the generated pdf.
The problem is that the PDF transcoder installs a TextPainter.
The original intent of this interface was to enable output modules
(like the PDF transcoder) to handle the rendering of text in special
ways. However in practice this hasn't really materialized.
Anyway the quickest solution (untested) is to remove the lines:
from xml-fop/src/java/org/apache/fop/svg/PDFTranscoder.java (line 177):
textPainter = new StrokingTextPainter();
ctx.setTextPainter(textPainter);
I code java all day, and so I could fix this if I had a few pointers/
time from my boss. If advice is forthcoming, I could probably get him to
agree to letting me fix it on company time [and release patches of course].
The real fix is to allow the FlowTextPainter to wrap the Text painter
that is passed to it's 'setTextPainter' method. This is a bit tricky
since the implementation of FlowTextPainter relies on
StrokingTextPainter methods which may not be available on the passed
in TextPainter (in which case you probably need to wire the calls to
the singleton StrokingTextPainter instance).
Or else refactor the interface entirely ;)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
