Mike Jarmy wrote:
I was actually able to get this working. It was only happening for certain files, and I do believe that it had something to do with URIs embedded in the svg file. By always setting the URI to an absolute path I was able to resolve the problem.
This indicates that the "wrong" thing is being used as a base URI, or that the resolver does not know what to do with the supplied base and relative URIs. This may be the fault of the resolver, or of your expectations.
This problem may however come back to bite me again. I have not yet experimented with reading SVG files from a jar file, as I will inevitably need to do. In that case I may have to disallow having SVG files refer to each other, since its likely there is no real way to specify a URI to another file inside a jar file.
I had to solve this problem when working with saxon8; the solution is to write a custom URIResolver, and make sure that whatever is doing the resolution uses it (this frequently involves a lot of redundant calls to setURIResolver, as the documentated behavior regarding propagation or "inheritance" of the resolver is wrong (or was as of Java 1.5). Once you do all this, you can resolve URIs relative to a base URI with a jar: scheme, and hence happily ref one svg (or xsl...) from another. The details of what you need to .setURIResolver() on surely differ between batik and saxon, but finding the correct victim is unlikely to be difficult. A related problem you may have with batik is that the SecurityManager doesn't allow you to do things you think are reasonable-at one point it was not possible to e.g. run rasterizer from the command line and resolve external URIs at all, without first essentially disabling the SM. I am unsure whether this is still the case. -- HH --------------------------------------------------------------------- To unsubscribe, e-mail: batik-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: batik-users-h...@xmlgraphics.apache.org
