>>>>> "GWJ" == G Wade Johnson <[EMAIL PROTECTED]> writes:

GWJ> Thomas, Thanks for your help on this so far.

GWJ> I've modified SVGImageElementBridge to give me a
GWJ> getReferencedDocument() method. Now, when I access what I thought
GWJ> was the Bridge for each <image/> I get null as the document. I
GWJ> have proven to myself that the member data is set correctly, so I
GWJ> assume that I'm not getting the Bridge correctly.

GWJ> How's the "right" way to get the Bridge associated with an
GWJ> Element?

     SVGOMElement.getSVGContext();  

     In dynamic documents this will return the bridge instance that
was used to build the corresponding GVT element.  So in your case:

    SVGImageElementBridge imgBridge;
    SVGOMElement imageElem = ....;
    imgBridge = (SVGImageElementBridge)imageElem.getSVGContext();

GWJ> G. Wade

GWJ> Thomas E Deweese wrote:
>>  >>>>> "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]

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]

Reply via email to