Well, calling fop.bat is the easiest way to integrate FOP. Keep in mind that XMLSpy is a Win32 application. I once invested quite some time to properly integrate FOP into a Win32 application (written in Delphi). JNI is not always easy to manage. I ended up deploying FOP as a webservice inside a Jetty container which was run inside the same process as the Win32 application. That gave me the least interaction with JNI (i.e. less debugging effort and no more access violations) and the most of the available functionality of FOP.
Things like that were also the reason I once started writing an abstraction API (currently calling this "JAXG") that would let you easily switch FO implementations while keeping most if not all of the API code the same. Editor makers like Altova don't want to be stuck with only FOP integration. Their users need to be able to switch the FO processor if they want. And every FO implementation has a command-line interface. Jeremias Maerki On 02.10.2007 19:07:10 Andreas L Delmelle wrote: > On Oct 2, 2007, at 15:55, Tobias Wehrum wrote: > > > <snip /> > > I now took a deeper look in the documentation and they say the > > arguments they pass to the FOP.bat are "-fo filename.fo -pdf > > fileame.pdf" - so the FO must've been build before this step. > > You're serious? Altova actually calls FOP using the fop.bat file? > What a waste! This means that both the JVM and FOP's FopFactory have > to initialize/warm-up for every separate FOP-run... :( > > There is still much to be learned over there, if you ask me. > > > Cheers > > Andreas --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
