[prev in list] [next in list] [prev in thread] [next in thread] 

List:       batik-dev
Subject:    Resolving URI's
From:       Peter Coppens <pc.subscriptions () gmail ! com>
Date:       2007-04-27 21:54:37
Message-ID: 10227095.post () talk ! nabble ! com
[Download RAW message or body]


Gentlepeople

Not sure this message is for the users' or the dev list list...i am guessing
the second, but forgive me if I guessed wrong

Anyway, I have been asking questions on the fop list to figure out how fop
when using batik for svg rendering deals with uri resolution. It appears the
two or completely separate beasts and not integrated at all....which is a 
pity really.

I kind of like the fop way of using the standard URIResolver class, but I
have the impression Batik has taken another route. If Batik would support a
URIResolver approach it seems it would be pretty straightforward to also
have fop use that feature and expose the same uri resolver feature (using
the same URIResolver class instance) to the end user.

So I guess my question is whether there are any plans for implementing the
possibility to use a URIResolver for Batik's uri resolution. 

If not would it all be possible to provide information (or pointer to) of
why Batik has chosen a different approach?

In order to get where I want (having my FOP URIResolver invoked whenever a
uri resolution action is needed irrespective of whether the uri is referred
from fo or svg) I guess there are two options.

The first is to implement a URIResolver approach in Batik (not a clue how
difficult that would be) and have FOP invoke that. The second is to bridge
the the current Batik URI resolution features with a URIResolver approach. 
I would prefer the first approach but it seems the most tricky, and having
some background on some of the design choices might help me.

Many thanks for any guidance,

Peter


-- 
View this message in context: http://www.nabble.com/Resolving-URI%27s-tf3660059.html#a10227095
Sent from the Batik - Dev mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org

[prev in list] [next in list] [prev in thread] [next in thread]