Thank you for your answer, that's clear. I wasn't aware of the different uses of the jars by the various Batik applications.
As for the JAXP thing, I think you are right, as it is easy to use it, providing we know the main implementation class of the parser, it is not really a problem to deal with XMLResourceDescriptor. Hervé, ----- Original Message ----- From: "Vincent Hardy" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, March 31, 2003 9:22 AM Subject: Re: Two questions about the latest Batik version > Hello Herve, > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
