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,

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.


[1] http://www.ikvm.net

Jeremias Maerki

Reply via email to