>>>>> "GWJ" == G Wade Johnson <[EMAIL PROTECTED]> writes:
GWJ> Well, it almost does what I need.<shrug/> - I can find the
GWJ> documents attached to the images. - I can manipulate those
GWJ> documents. - The changes appear in the DOM for the subdocuments.
GWJ> - The changes don't appear on the screen.
What if you 'force a repaint' do the changes show up?
You can generally force a repaint by panning around a bit.
GWJ> Unless I can find a way to get the images to update after they
GWJ> change, I'll have to either combine the files (which makes them
GWJ> huge) or implement something specific to Batik.
GWJ> Thanks again for all of your help.
GWJ> G. Wade
GWJ> Thomas E Deweese wrote:
>> >>>>> "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]
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]
