>>>>> "GWJ" == G Wade Johnson <[EMAIL PROTECTED]> writes:
GWJ> I've been working on the SVGOMImageElement trick. I finally
GWJ> worked my way down to getting the SVGImageElementBridge object
GWJ> associated with each image in the SVG file. So far so good.
GWJ> Unfortunately, the imgDocument field in the SVGImageElementBridge
GWJ> is protected. I even tried to derive a class from
GWJ> SVGImageElementBridge to get access and can't. Any ideas or have
GWJ> I run down the wrong trail?
The simplest thing to do is to make modifications to the Batik
Source. So you can add a new method getReferencedDocument() to the
Bridge that returns the protected member.
If this makes you squemish you can derive your own image element
bridge from Batik's and register it through a BridgeExtension - then
your bridge will get created/called instead of the default one. The
batik.extension.svg.BatikBridgeExtension is a fairly good example of
how to setup a bridge extension (although it doesn't override any of
the standard elements). This uses the java 'Services' convention so
you will need to create a services file that advertises your extension
(see
xml-batik/resources/META-INF/services/org.apache.batik.bridge.BridgeExtension).
However the thrust of my suggestion was to add a new method to
batik.dom.svg.SVGOMImageElement something like 'Document
getReferencedDocument()'. Then implement this like most of the SVGDOM
is by defining an interface (like batik.dom.svg.SVGTextContent) that
is then implemented by the Bridge. The bridge that was used for each
element is tracked and is available from SVGOMElement.getSVGContext();
(see batik.dom.svg.SVGTextContentSupport - To separate the dynamic
stuff from the strict DOM stuff most of the mucking is done in
XXXSupport classes (SVGLocatableSupport is another example).
Then in your code you just need to cast to SVGOMImageElement to
get the Document (no obvious mucking with bridges needed).
For this to become part of Batik (assuming you are interested) it
would require a contribution agreement (and it would probably wait
until after 1.5 goes final) - So you may want to use the
BridgeExtension which shouldn't require modifying any Batik code just
extending it.
I know, I know - more work... :)
GWJ> G. Wade
GWJ> "G. Wade Johnson" wrote:
>> Thomas,
>>
>> Thanks again. Everytime you answer a question for me, I find myself
>> with a lot more work.<grin/>
>>
>> >From what you've said, it looks like my best bet is to try (in
>> order):
>>
>> 1. SVGOMImageElement trick.
>>
>> 2. Build up composite on the fly. - Obvious, but I didn't think of
>> it.
>>
>> 3. Multiple JSVGCanvas objects. - I had thought about not needing
>> to rerender unchanged layers.
>>
>> With the multiImage idea, I'm not sure if the lazy evaluation will
>> cause me grief or not, so I'll save it.
>>
>> I'll try and post what I find for anyone else who runs into this
>> idea.
>>
>> Later, G. Wade
>>
>> Thomas E Deweese wrote:
>> >
>> > >>>>> "GWJ" == G Wade Johnson <[EMAIL PROTECTED]> writes:
>> >
>> > GWJ> I think I know the answer already, but I'm going to ask
>> anyway. > GWJ> Overview: I have an application where I will need
>> to display > GWJ> multiple SVG images on top of (or behind) one
>> another. I will > GWJ> also need to manipulate various elements on
>> various images. The > GWJ> some of these layers may be invisible
>> until triggered by a user > GWJ> action.
>> >
>> > GWJ> 1. I can generate the visual effect I want with the <image/>
>> element. > GWJ> a. This allows me to load multiple SVG files that
>> I can map to the > GWJ> same space. > GWJ> b. However, I cannot
>> find a way to "reach into" the SVG in the > GWJ> image to
>> manipulate internal elements.
>> >
>> > This should be doable. As far as reaching into to sub SVG this >
>> is a pretty small enhancement to the existing DOM. The >
>> BridgeUpdateHandler for the SVGOMImageElement already has a
>> reference > to the referenced document. This would of course be a
>> non-standard > SVG DOM (at least right now).
>> >
>> > GWJ> 2. I have seen the <multiImage/>/<subImageRef/> system. It
>> be able to > GWJ> tie loading multiple images depending on zoom. >
>> GWJ> a. I assume that I would have the same manipulation problems
>> as > GWJ> with the <image/> element.
>> >
>> > Yes, in fact they would be a bit worse because the way >
>> multiImage is implemented is 'lazy' so normally not all documents
>> are > loaded and also there is no 'one document' associated (in
>> fact I'm not > sure how this would make sense in the context of a
>> central application > tweaking docs since you would have to
>> 'retweak' documents when > resolutions changes).
>> >
>> > GWJ> b. The files are supposed to be viewable by other SVG
>> viewers, > GWJ> although the manipulation features are only
>> available in my > GWJ> application. I'm not sure how these elements
>> would play with > GWJ> other viewers.
>> >
>> > You can fairly easily use 'switch' and 'requiredExtensions' to >
>> fall back to a standard image element when needed (i.e. anything
>> but > Batik :).
>> >
>> > GWJ> 3. There have been a few questions in the past on this list
>> about > GWJ> layering JSVGCanvas objects and displaying one on top
>> of another. > GWJ> a. I don't know if anyone has ever gotten this
>> approach to > GWJ> work.
>> >
>> > I've never tried it directly but I do know that transparent >
>> backgrounds work for the JSVGCanvas and this is probably the most >
>> important piece.
>> >
>> > GWJ> b. I assume I could just walk a list of documents and
>> manipulate > GWJ> all appropriate elements on each document.
>> >
>> > Sure you would have a list of JSVGCanvas's and you can get the >
>> document from them.
>> >
>> > GWJ> Does anybody have any other ideas or comments on these
>> ideas?
>> >
>> > You might consider building the composite document yourself >
>> (fetch each of the 'sub documents' and build the composite document
>> on > the client). This would solve the 'reaching into' issue and
>> allow you > to only have one JSVGCanvas.
>> >
>> > One other issue you might not have considered is that by using >
>> multiple JSVGCanvas's you have the potential advantage that a >
>> modification in on layer would not require all the layers to
>> re-render > (the JSVGCanvas maintains an offscreen buffer which all
>> the other > layers could use).
>> >
>> > GWJ> Thanks, G. Wade
>> >
>> > GWJ>
>> ---------------------------------------------------------------------
>> > GWJ> To unsubscribe, e-mail:
>> [EMAIL PROTECTED] > GWJ> For additional
>> commands, e-mail: [EMAIL PROTECTED]
>> >
>> > ---------------------------------------------------------------------
>> > 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]
GWJ> ---------------------------------------------------------------------
GWJ> To unsubscribe, e-mail: [EMAIL PROTECTED]
GWJ> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
