On Tue, 2002-07-23 at 00:10, Kevin O'Neill wrote: > I'm new to fop, so please give me a little leeway :). > > I've been looking at FOPs PDF library to help me with some direct PDF > generation tasks that are not presently suited to XSL:FO (I need > absolute positioning, layering and the ability to use XObject Forms). > > FOP has about the nicest and low level PDF library I've come across, a > true undiscovered gem. > > Enough of the glowing praise :). > > I've noticed from the CVS logs that the separation of the PDF code is a > recent thing; are there current plans to extend it's usefulness beyond > that of mealy being an output renderer for FOP?
There aren't any specific plans in that direction but you can always make some if you want :) > Would you consider > adding contributed classes (like the aforementioned XObjectForm) that > there is no real XSL:FO imperative for? I was considering using XObject forms to render embedded svg so that it can be reused in the pdf document without redrawing the svg (for static regions etc.). So there may well be an XSL:FO use for it anyway (along with other ideas like reusing for table headers, static regions that are the same on each page). So we would definitely consider it! > Separating the generation of the > PDF support into an additional build target for people like me who what > to use the PDF functionality without the additional XSL:FO components? I don't see why not. In general it is a good idea to keep independant parts of the code separate. This will promote that more. We now have a pdf-transcoder target that builds just a jar that can be used as a transcoder for batik. We could split things up further and have: pdf jar, svg stuff jar, hyph jar, the rest jar. Keiron. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
