Hi gang, as you know we've have several inquiries in the past about compiling FOP with GNU Classpath for use in VMs such as Kaffe or natively on Unixes (using GCC/GCJ) and about running Apache FOP under .NET. I've done some experiments last week in this direction and here's what I found out:
After removing Batik as a dependency for FOP allows FOP to run and compile under IKVM [1]. So far, I've managed to run FOP from the command-line as an EXE file on Windows to create PDF files. No fancy tests, yet. I'll try to see what needs to be done to call FOP from a C# application by compiling FOP and its dependency into DLLs. Batik has the problem that it relies on com.sun.* classes which has been brought up on batik-dev. (Thomas, just so you know, I'm working on that one. I'll drop a note on batik-dev about that shortly.) Given this problem it's currently not possible to compile Batik for use in Kaffe or IKVM (both use GNU Classpath). Furthermore, it seems that the AWT implementation of IKVM is unfinished and results in runtime errors (which have nothing to do with the com.sun.* classes) when forcing IKVM to run a precompiled Batik JAR. Since we've also heard several voices who would like the Batik-dependency to be optional for FOP (to reduce JAR size), I'd like to propose making it so by extracting the SVG support from the main codebase. Some of this will be done anyway, as we're going to move stuff out to XML Graphics Commons. I'm not sure about the placement of the sources, yet. There are several possibilities: (1) Move optional FOP extensions (SVG and MathML) to src/extensions/<name>/java (where <name> is "svg" or "mathml"). (2) Move optional FOP extensions to src/optional/java along with code for JAI, JIMI and similar things. (3) Move FOP extensions under src/java/org/apache/fop/extensions/<name> where all the various sources will be concentrated. ATM, the SVG support classes are scattered over the whole codebase which I don't like so much. I'm open for additional suggestions. Generally, I don't like having all the code in one tree but in XML Graphics Commons this approach has won, too. I think having the opportunity to provide a .NET version of FOP would widen the number of potential users considerably especially since to my knowledge there's no usable open source .NET FO implementation out there. Depending on the license situation (IKVM is BSD but GNU Classpath is LGPL) we could even think about distributing .NET binaries. WDYT? [1] http://www.ikvm.net Jeremias Maerki
