On Mon, 15 Aug 2005 08:20 pm, Jeremias Maerki wrote:
> On 15.08.2005 14:04:16 Manuel Mall wrote:
> > On Mon, 15 Aug 2005 06:43 pm, [EMAIL PROTECTED] wrote:
> > > http://issues.apache.org/bugzilla/show_bug.cgi?id=36082
> > >
> > > ------- Additional Comments From [EMAIL PROTECTED]  2005-08-15
> > > The URI Resolution does not yet affect URIs in Batik.
> >
> > Hmm, I do set the baseURL when processing a SVG e-g. Do you have an
> > example?
> 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
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?

> > > - The ImageFactory should not rely on the InputStream on the
> > > StreamSource to be set, as components like XML Commons Resolver
> > > don't do that. They only set the resolved URL on a
> > > (Stream?)Source object. This means that in the FOUserAgent, a
> > > Source should be returned, not a StreamSource. For SVG graphics
> > > you might even want to supply a DOMSource, but that's only
> > > nice-to-have and for later. I'm resolving this issue now since
> > > it's purpose is fulfilled now.
> >
> > I was considering that as well but I am still hesitant to change
> > internal interfaces around too much. If it is agreeable to either
> > abolish the FOUserAgent.getStream() function or replace it with a
> > getSource() function I'll be happy to do this.
> I'd actually simply call it "resolveURI(String)" and return a Source,
> similar to the resolve() method in URIResolver. Source and its
> implementations provide all the different access variant for getting
> at sources. ATM, it suffices to support arbitrary sources which
> simply return a SystemID (which you can simply convert to a URL) and
> StreamSource whose getInputStream() returns a non-null value which
> you already implemented. DOMSource can wait till later and other
> stuff can be added as needed. We simply need to support providing
> InputStreams (done) and XML Commons URIResolver (open).
OK, will do.

> Jeremias Maerki

Reply via email to