First of all, the SVG handling code in FOP (except for the XMLHandlers) among other stuff will move out of FOP. See here: http://wiki.apache.org/xmlgraphics/XmlGraphicsCommonComponents
I assume this will happen after the first preview release and after you finish your work on FOrayFont integration so we don't complicate this more than necessary and so we don't delay the first FOP release unnecessarily especially since XML Graphics Commons would need to be released, too, prior to making a FOP release. And Commons as still empty. :-) On 12.09.2005 15:27:03 Vincent Hennebert wrote: > I'm about to convert the SVG library to FOrayFont. But the Batik side seems > to > be reluctant to see the transcoders converted to FOrayFont [1]. > How should I handle that? I guess I should leave existing files as is and > provide new files corresponding to the FOrayFont implementation? How should I > name them? Perhaps a new subpackage? Let's identify the problem points first: PDFGraphics2D and PSGraphics2D: drawString() methods PDFDocumentGraphics2D and AbstractPSDocumentGraphics2D: font setup code The TextElementBridges and the TextPainters are no problem because they are plug-ins already and are thus optional for Batik. We can have multiple implementations of the TextBridges if necessary. Without the TextElementBridge Batik will paint all the text as shapes and thus use Java2D's font subsystem. For the drawString() methods we can create simple plug-ins much like the TextElementBridges which are called by the drawString() methods. Two implementations of the plug-in interface: One to paint using the new font subsystem and one that uses the Java2D font subsystem which should probably paint the text as shapes. The latter implementation can be done later when necessary as Batik paints all text through the TextBridge as far as I could see. For the DocumentGraphics2D classes can simply be subclassed to add font subsystem-specific code. PSDocumentGraphics2D and PSTranscoder can be removed entirely IMO. EPS should be enough for all cases, I think. The only use case for the PSTranscoder I can think of is for "SVG Print", but that's easily done later again if someone really needs it again. ATM, don't bother changing any packages. All classes will be repackaged during the move to XML Graphics Commons. I can only see a few new classes in the existing packages. > For pdf, does it concern other files than those in the svg subpackage? No. > Which files in the render.ps subpackage are concerned? PSGraphics2D, AbstractPSDocumentGraphics2D, PSDocumentGraphics2D, PSTextElementBridge, PSTextPainter, AbstractPSTranscoder and PSFontUtils, I think. > What about the pdf library? That's the big question mark for me. The PDF library should be made as font subsystem agnostic as much as possible, so Batik can use the PDF library without a mandatory dependency on FOrayFont. I haven't investigated any details here, yet. The same point obviously apply for the PS generation code of which mainly PSFontUtils has a reference on the font subsystem. At least, PostScript will be a lot easier to handle than PDF. > All this is still a bit unclear in my head. > In two words: please help... Well, I hope this helps a bit. I'll look a little more closely into the PDF library. Jeremias Maerki
