As you may have see, I've reimplemented the PDFTextPainter which is part
of the PDFTranscoder. All most all text is now painted using PDF text
painting primitives (except for SVG fonts and where filters are used).
The advantages: smaller PDF files, better visible quality, copy/paste
is possible.
Change:
http://svn.apache.org/viewvc?rev=591587view=rev
Implementation notes:
- The text painter has a fallback so it can still paint text with SVG
fonts. Text for which there's no font in FOP's FontInfo object will be
painted using shapes as before.
- I've reenabled the stroke text switch so you can switch to text as
shapes if anything goes bad (which it shouldn't as the new code is
already well tested).
- By default, I've enabled the PDFTrancoder to make use of FOP's font
auto-detection, so no additional configuration should be necessary to
handle most cases.
- During testing I found that at least on Windows, Sun J2SE 6.0_03
doesn't register Type 1 fonts (like Helvetica) in the Java AWT font list.
That can lead to unexpected font substitution.
- On Linux with J2SE 1.5, my client saw some unexpected behaviour in
terms of font selection which may have to do with either Linux itself or
the JVM. We haven't found out. Installing the right fonts and removing
others helped in this situation.
- The above two points are most likely due to the approach I've taken.
The insider will notice that I've extended the StrokingTextPainter which
means that all text is internally built up using shapes but effectively
painted using PDF text by the PDF TextPainter. That way I didn't have to
reimplement a lot of the flow text functionality. Actually, I've managed
to implement all this with next to no changes in Batik itself (just a
nit. Cameron has taken care of my patch. Thanks!). All this naturally
means, I rely on the font metrics from the AWT subsystem and I just
carefully position each glyph at the position where the Stroking
TextPainter would have painted each glyph as shapes. Now, if no
equivalent font is found in the FontInfo object, the result will look
bad: for example, Times text with Arial font metrics. Fortunately, with
font auto-detection this problem usually doesn't appear. The visual
differences between the PNGTranscoder and the PDFTranscoder are minimal.
I've tested the whole W3C SVG 1.1 test suite.
- I've investigated what it would take to hook FontInfo into Batik's
font subsystem. It looked like too much work for the benefit I get. Just
so you know there's still room for improvement, but for now I've
followed the 80:20 rule.
Feedback welcome. And yes, XSL-FO documents with embedded SVG profit
from these changes, too. :-)
Have fun!
Jeremias Maerki
