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=591587&view=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