On 10/20/2011 05:41 AM, Jeremias Maerki wrote:
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.
I did use a ParsedURLProtocolHandler, adding files to a global registry
(Weak map) and using UserAgent.get*Security() methods in order to not
allow one SVG to use files of another one. Still not the solution I
liked because this is server side code, and I am not very happy in
having a global synchronized store for those linked files
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: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
