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

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.


To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to