Re: Apache FOP on .NET
On 22.11.2005 15:39:24 Dalibor Topic wrote: 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. I currently don't have plans for that. But I'll look into it. In the meantime, I'm always available here on the mailing list and via Skype. I've also set up a Wiki page where we can track all the issues involved here. Help is welcome. http://wiki.apache.org/xmlgraphics/GnuClasspathCompatibility snip/ 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 than jikes. Good luck! I'll keep trying myself. snip/ Jeremias Maerki
Re: Apache FOP on .NET
Jeremias Maerki wrote: 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. I think that's a good move and definitely would be well accepted in the .NET community. I could help you on that. And besides IKVM what do yo uthink about other options - using J# or even porting to C#? -- Oleg
Re: Apache FOP on .NET
Hi Oleg, I see you're still a lurker. :-) J#: I don't know. It looks like you need a Visual Studio .NET license which I don't have. Was this what nfop was done with? I didn't look. C#: I don't have time to help with such an endeavour in the near future. That's a huge task. And the Java version takes effort enough at the moment. I know people who would be very interested to run FOP on .NET but for the moment I'm only going to take the easy road via IKVM so see where I get. But I guess one could think about creating additional source code in C# or any other .NET language to provide additional features that might be difficult with IKVM. Since IKVM has problems with AWT it might make sense to write a renderer in C# to do direct printing, for example. But my priorities are with PDF and PS at the moment. On 22.11.2005 10:27:09 Oleg Tkachenko wrote: Jeremias Maerki wrote: 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. I think that's a good move and definitely would be well accepted in the .NET community. I could help you on that. And besides IKVM what do yo uthink about other options - using J# or even porting to C#? -- Oleg Jeremias Maerki
Re: Apache FOP on .NET
Jeremias Maerki wrote: J#: I don't know. It looks like you need a Visual Studio .NET license which I don't have. Was this what nfop was done with? I didn't look. afair J# command line compiler is a part of .NET SDK. I'll check it out anyway. The main problem I think is that J# supports only Java 1.1.4 subset... C#: I don't have time to help with such an endeavour in the near future. That's a huge task. And the Java version takes effort enough at the moment. Ok, forget it. -- Oleg
Re: Apache FOP on .NET
On Tue, Nov 22, 2005 at 10:51:40AM +0100, Jeremias Maerki wrote: Hi Oleg, I see you're still a lurker. :-) J#: I don't know. It looks like you need a Visual Studio .NET license which I don't have. Was this what nfop was done with? I didn't look. C#: I don't have time to help with such an endeavour in the near future. That's a huge task. And the Java version takes effort enough at the moment. I know people who would be very interested to run FOP on .NET but for the moment I'm only going to take the easy road via IKVM so see where I get. But I guess one could think about creating additional source code in C# or any other .NET language to provide additional features that might be difficult with IKVM. Since IKVM has problems with AWT it might make sense to write a renderer in C# to do direct printing, for example. But my priorities are with PDF and PS at the moment. On a side note, an interesting way to get the AWT going on Win32 could be to use the Qt4 peers in GNU Classpath with a Qt4 build on Win32. You may want to see if Jeroen or someone on the IKVM list has looked that way. I've got the Qt4 peers working with Kaffe on Linux and OS X, but didn't have much time to play with Kaffe on Cygwin recently. cheers, dalibor topic On 22.11.2005 10:27:09 Oleg Tkachenko wrote: Jeremias Maerki wrote: 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. I think that's a good move and definitely would be well accepted in the .NET community. I could help you on that. And besides IKVM what do yo uthink about other options - using J# or even porting to C#? -- Oleg Jeremias Maerki
Re: Apache FOP on .NET
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 [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. 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 than jikes. 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
Apache FOP on .NET
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
Re: Apache FOP on .NET
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 [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. 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? 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. cheers, dalibr topic WDYT? [1] http://www.ikvm.net Jeremias Maerki
