Hi all,

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 [1] 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.

[1] 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. ;)

Reply via email to