Ignore my previous question. Of course, as soon as I gave up and asked, I realized that the SVGContext was the Bridge and all I had to do was call getSVGContext() and cast it to the right type.<action type="smack head on desk"/>
Thanks for the help. G. Wade 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
