I've looked into this some time ago. My idea was to add support for JAXP URIResolvers like we did in Apache FOP. But ParsedURL seems to be so knit into Batik that it's difficult to do that (without major refactoring and API changes). Since I didn't have enough time, I resorted to a URL protocol handler that is globally registered. You could also implement a ParsedURLProtocolHandler but they are maintained in a static variable in ParsedURL, so they, too, are global. No connection with the user agent. For me, the normal URL protocol handler works well enough for now, but I'm not entirely happy.
On 19.10.2011 23:00:20 Robert Marcano wrote: > Greetings. > > I have been using Batik for a few years and I love its extensibility. I > even use the CSS Engine directly for a non SVG dialect document without > needing to add another library. > > My problem right now is that I need to run/paint the SVG file inside > some kind of virtual filesystem. The linked files inside the SVG > (xml-stylesheet processing instructions, images...) are not on a real > filesystem, they are on RAM isolated from any other SVG loaded. I tried > using ParsedURL to define a new protocol but despite the advantages of > it over the standard URL class, It still has the problem that protocol > handlers are global, I haven't found a way to isolate a protocol for > only a SVG document (I set the ParsedURL on the document directly > because there is no real URL for it). I tried using ThreadLocal to > create a ParsedURL protocol handler context aware, but I found many > problems with this approach, Batik is not single threaded, some external > to the svg resources are loaded with parsing, some of them are loaded on > threads created by Batik out of my control (script on the document that > add elements linking to external resources), so there is no easy way to > use a ThreadLocal for that. > > It would be nice if Batik could be extended with a VFS layer in order to > be able work with svg files that resides on things not directly mapped > to a virtual protocol, but that is something that I could hack a little > later, in the short them I need to solve this problem with something > less intrusive in the Batik codebase. Any help is really appreciated. > > Note: I thought about registering those virtual files on some kind of > global registry and then create a protocol handler accessing that > registry but I am trying to avoid anything with globals because I need > very good isolation between docs. > > Thanks in advance Jeremias Maerki --------------------------------------------------------------------- To unsubscribe, e-mail: batik-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: batik-users-h...@xmlgraphics.apache.org
