J. Pietschmann wrote: > Chris Pratt wrote: > > I'm using FOP 0.20.5 and I've coded myself into a corner. We generate some > > rather large PDF files using fop (lists of every eye doctor in California > > for example), which can be very processor and very memory intensive. To > > limit the overhead I wrote a caching scheme that caches the complete PDF > > files for easy re-use. Worked really well until the powers that be decided > > that each of the PDF's needed to be personalized. > > > > Looking around for an alternative to just removing the caching, I found PDF > > Forms which would probably do the job. I don't expect that FOP has any > > ability to fill in forms of already generated PDF Forms, but I was hoping > > that it might have the ability to generate them. Does anyone have a clue > > how I might go about this? Or maybe an altogether better way of solving the > > problem? Thanks. > > (*Chris*) > > There was an extension floating around two years ago which allowed > to inject raw PDF through FOP into the result. The originator used > this basically to create PDF forms. Of course, you'll have to invest > some time to grok the PDF spec. Check the FOP list archive. > > Alternatively, you can try to postprocess pregenerated PDF with > another tool. Check the FOP website (FAQ) for hints.
I have had no luck in locating the extension, but it got me thinking about how it might be implemented. How hard would it be (taking in mind that I am an experienced Java coder, but have never looked at the FOP source) to add an fo:instream-foreign-object implementation (similar to the Batik SVG support) that could process the XForms specification [http://www.w3.org/TR/2003/REC-xforms-20031014/], or maybe a subset, and do the right thing in the PDF file? (*Chris*) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
