Well, it almost does what I need.<shrug/> - I can find the documents attached to the images. - I can manipulate those documents. - The changes appear in the DOM for the subdocuments. - The changes don't appear on the screen.
Unless I can find a way to get the images to update after they change, I'll have to either combine the files (which makes them huge) or implement something specific to Batik. Thanks again for all of your help. G. Wade 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
