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
> > 12:43 ------- Applied. Thanks a lot, Manuel. This is a big step in
> > the right direction!
> > http://svn.apache.org/viewcvs?rev=232786&view=rev
> > I'll commit a couple of JUnit test cases in a minute that uses a
> > custom URIResolver and demonstrates how this stuff is used. It also
> > shows a couple of problems the will eventually need to be solved:
> > - 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
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.
> > - 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).