Hervé Girod wrote:
Hello !
I have two questions (or propositions) about the latest version of Batik :
jar dependencies :
* why not shipping in one jar batik-dom.jar, batik-xml.jar, and batik-css.jar, as they seem to behave together ? * I have the same remark about batik-util.jar, batik-gui-util.jar, and batik-ext.jar
The way this was packaged (you have to look at the binary distribution), is that the various application jars (e.g., squiggle, rasterizer, etc) share a common set of jars in the distribution's lib directory (e.g., batik-ext.jar). So, for example, batik-dom.jar is used by the browser and by the prety printer, but batik-css.jar is not used by the pretty printer.
In a nutshell, the jars were broken down in re-usable, sharable pieces. Another option would have been to do what you suggest, but then each application would have used a jar (or jars) bigger than necessary. There are pros and cons for each approach I think.
Note: to see the lib/*.jars use, you can have a look at the sources/*.mf manifest files.
Use of XML parser when reading an SVG file:
The XMLResourceDescriptor class define which XML driver will be invoked by batik. It is possible to use the default JRE 1.4 parser (crimson !!), by setting the parser main class name (as "org.apache.crimson.parser.XMLReaderImpl"). It works apparently well on some examples.
That's right. JDK 1.4 includes a version of Crimson and of the XML APIs which do not conflict. As I mentioned in previous emails, the problem we ran into is that xml-apis.jar that we use (for compatibility with other Apache project such as FOP) is not compatible with the latest Crimson version. However, if you put Crimson and a compatible version of the XML APIs first in your classpath (which is what is happening with JDK 1.4 because these are in the boot path), then you can use Crimson.
Why not use the JAXP API to parse SVG files ? I don't think it would be very complicated, but I haven't thouroughly review the code, so I'm not sure it would be so simple...
Some of the commiters felt that it was not appropriate to add another JAR in our distribution if not necessary. So the proposal was to use the XMLResourceDescriptor class to define the parser class. The idea is that it works without JAXP and it works with JAXP because you can always use JAXP to figure out what the parser class name is and set this into XMLResourceDescriptor (it has an xmlParserClassName).
If there is a strong feeling from the Batik users and developers that people would rather see us use JAXP directly then we could change this. However, even though I have a lot of sympathy for using JAXP (this is a battle I lost long ago :-^), I am relunctant to change this for 1.5 final as the plan is to not change anything unless it is broken, and I do not think this is broken.
Thanks, Vincent.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
