Re: rendering directly to java.awt.Graphics2D

On Tue, Aug 9, 2011 at 6:59 PM, Henryk Hecht <[email protected]> wrote:
> 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.

Thanks for the tip Henryk -- I will certainly need to use a custom
URIResolver.
Our framework actually allows URIs to be chained together in an ad-hoc
manner to provide things like remote file access.  So my current 'solution'
was really a hack that chopped off everything but the last URI.  A custom
resolver should be just the ticket.

-- Mike Jarmy