Anthony Green wrote:
If anybody is interested in running batik on our free stack, here's some info on what needs doing...
Has anybody been working on this? We'd be interested in using Batik to rasterize SVG content for Wikipedia, and as we have a bit of a free software fetish it would be nice to make sure it can run under GCJ.
(Currently we're using librsvg, which is not totally satisfactory as there are some things it doesn't render too well.)
If nobody's working on it, I might pick it up sometime in the next while depending on how hard it looks. :)
-- brion vibber (brion @ pobox.com / brion @ wikimedia.org)
--- Begin Message --- From: Thomas DeWeese <Thomas DeWeese Kodak com> To: batik-dev xmlgraphics apache org Subject: Re: com.sun.image.* Date: Wed, 24 Aug 2005 20:05:34 -0400 Hi Anthony,
Anthony Green wrote:
batik 1.6 (as packaged by jpackage.org) builds nicely on the FedoraCore 4 Linux distribution with a fully Free and Open Source java stack (gcj, the Eclipse compiler, etc), with the exception of a few classes using com.sun.image.codec.jpeg.*.
The com.sun.image.code.jpeg.* classes aren't part of the standard java platform, and there are no Free or Open Source implementations of the classes available for us to use. Can similar functionality be achieved through the use of core classes, like ImageIO?
I would imagine so. There are some potential issues with the handling of colorspaces but my understanding is that imageio tends to be more complete in general.
If so, are there any plans for such a migration?
The basic problem is that javax.imageio is only available in JDK 1.4 and higher. Currently Batik target's 1.3 and higher. However we recently created a source tree for JDK 1.4 specific classes (only compiled for JDK 1.4 of course). So it might be possible to add to the current support with this.
Getting batik to build with free software solutions opens the door to including it, and applications that depend on it, in fully free Linux distributions, like Fedora and Debian.
Any help from the these communities would be very welcome!
On Wed, 2005-09-28 at 23:27 -0700, Brion Vibber wrote:
If nobody's working on it, I might pick it up sometime in the next while depending on how hard it looks. :)
As far as I know nobody is working on this, so... go for it!
And then look for your name when I edit http://en.wikipedia.org/wiki/Hero
:-)
AG
On Wed, 2005-09-28 at 23:27 -0700, Brion Vibber wrote:
Anthony Green wrote:
If anybody is interested in running batik on our free stack, here's some info on what needs doing...
Has anybody been working on this? We'd be interested in using Batik to rasterize SVG content for Wikipedia, and as we have a bit of a free software fetish it would be nice to make sure it can run under GCJ.
(Currently we're using librsvg, which is not totally satisfactory as there are some things it doesn't render too well.)
If nobody's working on it, I might pick it up sometime in the next while depending on how hard it looks. :)
Brion - have you looked into this at all?
The Fedora docs people would like to use FOP to help convert DocBook XML into various outputs using a fully free stack. Unfortunately FOP depends on Batik....
AG
Anthony Green wrote:
On Wed, 2005-09-28 at 23:27 -0700, Brion Vibber wrote:
Anthony Green wrote:
If anybody is interested in running batik on our free stack, here's some info on what needs doing...
Has anybody been working on this? We'd be interested in using Batik to rasterize SVG content for Wikipedia, and as we have a bit of a free software fetish it would be nice to make sure it can run under GCJ.
(Currently we're using librsvg, which is not totally satisfactory as there are some things it doesn't render too well.)
If nobody's working on it, I might pick it up sometime in the next while depending on how hard it looks. :)
Brion - have you looked into this at all?
I've looked a little bit at the files but haven't had a chance to try actually working on it. If someone else is itching to work on it, PLEASE feel free to start!
The Fedora docs people would like to use FOP to help convert DocBook XML into various outputs using a fully free stack. Unfortunately FOP depends on Batik....
-- brion vibber (brion @ pobox.com)
On Wed, 2005-10-19 at 11:31 -0700, Brion Vibber wrote:
I've looked a little bit at the files but haven't had a chance to try actually working on it. If someone else is itching to work on it, PLEASE feel free to start!
Ok, thanks for the update Brion.
I'm wondering if the simplest solution for the Fedora Docs team is for us to strip out Batik's JPEG handling. Perhaps it's not required for their work-flow.
Karsten - can you provide some simple docs and show us how you would process them using a proprietary Java solution? We should be able to determine from this whether or not we can ignore the problem classes (as a near term solution).
Thanks,
AG
On Wed, 2005-10-19 at 16:11 -0700, Anthony Green wrote:
I'm wondering if the simplest solution for the Fedora Docs team is for us to strip out Batik's JPEG handling. Perhaps it's not required for their work-flow.
It turns out that it's impossible to simply strip out the JPEG code because some of the proprietary Sun JPEG APIs are used for more general non-JPEG tasks. "Liberating" Batik will take some real effort (I'm looking for a cheap solution right now - since this is something we want in the FC5 timeframe).
So, the next option is to look at using FOP without Batik. If this is even possible I suppose this means no SVG processing in FOP. Perhaps the doc generation work-flow could be tweaked to pre-render the SVG into some format FOP can handle. I'll poke at this a little.
AG
On Fri, 2005-10-21 at 16:28 -0700, Anthony Green wrote:
So, the next option is to look at using FOP without Batik. If this is even possible I suppose this means no SVG processing in FOP.
This isn't possible. Batik is fundamental to getting fop to work.
We're stuck until somebody tackles Batik.
AG
On Fri, 2005-10-21 at 19:26 -0700, Anthony Green wrote:
On Fri, 2005-10-21 at 16:28 -0700, Anthony Green wrote:
So, the next option is to look at using FOP without Batik. If this is even possible I suppose this means no SVG processing in FOP.
This isn't possible. Batik is fundamental to getting fop to work.
We're stuck until somebody tackles Batik.
Ok, so I tackled Batik and have an SRPM that builds now. This basically boiled down to removing JPEG and TIFF image handling, but - in theory - PNG support should work. The changes weren't nearly as bad as I first thought. Other than removing classes from the build, I only had to add two patches.
But now we're stuck on GNU Classpath/libgcj not implementing some core AWT functionality in java.awt.BasicStroke.
There was already a bug filed for this: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22938
gnu.java.awt.peer.gtk.GdkTextLayout.getCharacterLevel(int) is also a problem.
Hopefully somebody (fitzsim?) can comment on the status of these classes.
This goal of rendering Fedora docs on a free stack is beginning to look like an FC6 goal.
AG
On Sat, 2005-10-22 at 12:09 -0700, Anthony Green wrote:
On Fri, 2005-10-21 at 19:26 -0700, Anthony Green wrote:
On Fri, 2005-10-21 at 16:28 -0700, Anthony Green wrote:
So, the next option is to look at using FOP without Batik. If this is even possible I suppose this means no SVG processing in FOP.
This isn't possible. Batik is fundamental to getting fop to work.
We're stuck until somebody tackles Batik.
Ok, so I tackled Batik and have an SRPM that builds now. This basically boiled down to removing JPEG and TIFF image handling, but - in theory - PNG support should work. The changes weren't nearly as bad as I first thought. Other than removing classes from the build, I only had to add two patches.
But now we're stuck on GNU Classpath/libgcj not implementing some core AWT functionality in java.awt.BasicStroke.
There was already a bug filed for this: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22938
gnu.java.awt.peer.gtk.GdkTextLayout.getCharacterLevel(int) is also a problem.
Hopefully somebody (fitzsim?) can comment on the status of these classes.
Yeah, there are two large chunks of work still to do in the GTK peers; port GdkGraphics2D to Cairo 1.0 and implement java.awt.font using Pango and Freetype. I'm hoping to finish the first task before FC5, but the second one will likely have to wait.
Tom
This goal of rendering Fedora docs on a free stack is beginning to look like an FC6 goal.
AG
java-devel@lists.fedoraproject.org
-
Anthony Green -
Brion Vibber -
Thomas Fitzsimmons