On Mon, 15 Aug 2005 08:20 pm, Jeremias Maerki wrote:
This is actually not about relative paths, but actual URI resolution. If you look at the JUnit test case I committed earlier  I use the URIResolver to resolve an URI "funky:myimage123" to one of the bgimg bitmaps in our test directory (a file URL). That's how people can specify abstract URIs instead of concrete URLs to point to resources whose location is not known at deployment time. And it's where XML Commons Resolver jumps in to provide a widely used mapping from URIs to URLs.  http://svn.apache.org/viewcvs?rev=232788&view=rev
Manuel Mall wrote:
Alright, this means we need to set the FOP resolver on the SVG processor. Not sure if Batik supports the javax.xml.transform.URIResolver interface. May be any Batik people lurking on this list can shed more light on this?
All Batik URL resolution is handled by our ParsedURL implementation. The only 'problem' with the ParsedURL class is that it doesn't have a very direct connection to a UserAgent, so configuration is done on a per JVM (really classloader) basis. So it would be simple to add support for URIResolver in ParsedURL but it wouldn't be a parameter on the 'batik.transcode.Transcoder' class it would be global. I'm not sure if this is a problem or not (I didn't follow all of the discussion above). There is also the potential issue of dragging in a new dependency for an interface with a single method that only takes/returns primitive types. ;)