On Tue, Nov 22, 2005 at 09:12:05AM +0100, Jeremias Maerki wrote:
> Hi Dalibor
> Good thing you're still lurking! :-)
Well, FOP is very interesting for me in terms of having a free DocBook
toolchain on free runtimes that's well maintained. If you are around at
FOSDEM, it'd be great to have a small talk about FOP, Batik, XML
graphics and free runtimes, what works, what we still need, which areas
would need more work, etc.
> On 21.11.2005 23:48:37 Dalibor Topic wrote:
> > On Mon, Nov 21, 2005 at 10:29:18AM +0100, Jeremias Maerki wrote:
> > > 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 . 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.
> > Yay! Congrats all over!
> > > 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.
> > Yup. I was under the impression that the XML graphics project would help
> > work around the most dire problems, though. Right?
> As much as we can, anyway. I'm working on that. I don't think I'll be
> able to help improving IKVM. GNU Classpath might be easier to help with,
> but then I still don't have a clue how to work with GNU Classpath on
> Windows (Cygwin only coming with GCC 3.x, not 4.0). I haven't had the
> time to help myself to a true Unix environment, yet. I've got access to
> two Unix systems, both of which don't have GCC/GCJ installed and I have
> limited knowledge on unixish systems to simply know how to install
> additional software (if I'm allowed at all). And then I hate C/C++ and
> having to apply patches before I can compile some software. :-) So this
> means that it takes a lot of nerves to go after this.
Heh, I know, I know ... I can't build Kaffe on Cygwin without a patched
up jikes, with Davanum's patches from CVS, etc... I need to pickup my
conversation with Cygwin packagers to see if we can get Kaffe packaged
in there. With the recent CVS head it's possible to use Kaffe with GNU
Classpath like with JamVM, and other runtimes, but it's still some time
to go until I release 1.1.7.
I'll play around a bit with gcjx on cygwin, to see if it works better
> > > 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.
> > +1
> > > (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.
> > GNU Classpath is more liberally licensed than LGPL, actually ;) It's the
> > GPL with a big fat linking exception, that puts no restrictions on the
> > license
> > of the linking code.
> Oops, sorry, looks like I had the wrong idea in mind. There was so much
> talk within the ASF about LGPL that I assumed Harmony's problem was with
> the LGPL.
LGPL is mopstly important because of Hibernate, afaik. But it'd be an
interesting milestone in terms of how much copyleft is acceptable in
what sort of dependencies. And most discussion atm from outsiude seems
to be around which sort of copyleft licenses are OK in which dependency
situations (MPL, CDDL, LGPL, you name it). So if the LGPL/MPL/CDDL etc
pass, I guess a more liberal version of the LGPL would pass muster too.
We'll see how it goes.
> > cheers,
> > dalibr topic
> > > WDYT?
> > >
> > >  http://www.ikvm.net
> > >
> > > Jeremias Maerki
> > >
> Jeremias Maerki