You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-users@xmlgraphics.apache.org by "G. Wade Johnson" <wa...@abbnm.com> on 2003/05/28 19:01:41 UTC
Layering multiple SVG images
I think I know the answer already, but I'm going to ask anyway.
Overview:
I have an application where I will need to display multiple SVG images
on top of (or behind) one another. I will also need to manipulate
various elements on various images. The some of these layers may be
invisible until triggered by a user action.
1. I can generate the visual effect I want with the <image/> element.
a. This allows me to load multiple SVG files that I can map to the
same space.
b. However, I cannot find a way to "reach into" the SVG in the
image to manipulate internal elements.
2. I have seen the <multiImage/>/<subImageRef/> system. It be able to
tie loading multiple images depending on zoom.
a. I assume that I would have the same manipulation problems as
with the <image/> element.
b. The files are supposed to be viewable by other SVG viewers,
although the manipulation features are only available in my
application. I'm not sure how these elements would play with
other viewers.
3. There have been a few questions in the past on this list about
layering JSVGCanvas objects and displaying one on top of another.
a. I don't know if anyone has ever gotten this approach to work.
b. I assume I could just walk a list of documents and manipulate
all appropriate elements on each document.
Does anybody have any other ideas or comments on these ideas?
Thanks,
G. Wade
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: Layering multiple SVG images
Posted by "G. Wade Johnson" <wa...@abbnm.com>.
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 <wa...@abbnm.com> 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 <wa...@abbnm.com> 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:
> >> batik-users-unsubscribe@xml.apache.org > GWJ> For additional
> >> commands, e-mail: batik-users-help@xml.apache.org
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org >
> >> For additional commands, e-mail: batik-users-help@xml.apache.org
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org For
> >> additional commands, e-mail: batik-users-help@xml.apache.org
>
> GWJ> ---------------------------------------------------------------------
> GWJ> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
> GWJ> For additional commands, e-mail: batik-users-help@xml.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-users-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: Layering multiple SVG images
Posted by "G. Wade Johnson" <wa...@abbnm.com>.
Thanks, Thomas.
I'll keep looking at alternate approaches. (I'm hoping to redefine the
problem to one I can solve.<grin/>)
G. Wade
Thomas E Deweese wrote:
>
> >>>>> "GWJ" == G Wade Johnson <wa...@abbnm.com> writes:
>
> GWJ> I panned around all over the place with no update of the
> GWJ> images. I even panned far enough to move the image off the
> GWJ> canvas, but when I brought it back the images weren't updated.
>
> GWJ> I take it that this is not expected?
>
> Not what I had hoped for. This means that there is no connection
> being built between the referenced image DOM's and the parent
> document's rendering tree. This means that it would probably be a
> fair amount of work to get this to work (and I'm not certain where it
> would start)... :(
>
> I think your going to have to combine the documents on the
> client. Note that you can do this in JavaScript using 'getURL' - it's
> not standard (at least not yet) but everyone implements it (so it will
> work with other browsers). For the definition look at Adobe's
> document for ASV or our batik.script.Window class.
>
> GWJ> G. Wade
>
> GWJ> Thomas E Deweese wrote:
> >> >>>>> "GWJ" == G Wade Johnson <wa...@abbnm.com> 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 <wa...@abbnm.com> 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
[snip]
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: Layering multiple SVG images
Posted by Thomas E Deweese <th...@kodak.com>.
>>>>> "GWJ" == G Wade Johnson <wa...@abbnm.com> writes:
GWJ> I panned around all over the place with no update of the
GWJ> images. I even panned far enough to move the image off the
GWJ> canvas, but when I brought it back the images weren't updated.
GWJ> I take it that this is not expected?
Not what I had hoped for. This means that there is no connection
being built between the referenced image DOM's and the parent
document's rendering tree. This means that it would probably be a
fair amount of work to get this to work (and I'm not certain where it
would start)... :(
I think your going to have to combine the documents on the
client. Note that you can do this in JavaScript using 'getURL' - it's
not standard (at least not yet) but everyone implements it (so it will
work with other browsers). For the definition look at Adobe's
document for ASV or our batik.script.Window class.
GWJ> G. Wade
GWJ> Thomas E Deweese wrote:
>> >>>>> "GWJ" == G Wade Johnson <wa...@abbnm.com> 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 <wa...@abbnm.com> 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 <wa...@abbnm.com>
>> 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 <wa...@abbnm.com>
>> >> 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: >> >> >>
>> batik-users-unsubscribe@xml.apache.org > GWJ> For additional >> >>
>> >> commands, e-mail: batik-users-help@xml.apache.org
>> >> >> >> >
>> >> >> >> > ---------------------------------------------------------------------
>> >> >> >> > To unsubscribe, e-mail: >>
>> batik-users-unsubscribe@xml.apache.org >> > >> For additional >>
>> commands, e-mail: >> batik-users-help@xml.apache.org
>> >> >> >>
>> >> >> >> ---------------------------------------------------------------------
>> >> >> >> To unsubscribe, e-mail: >>
>> batik-users-unsubscribe@xml.apache.org >> For >> additional >>
>> commands, e-mail: batik-users-help@xml.apache.org
>> >> >>
GWJ> ---------------------------------------------------------------------
GWJ> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
GWJ> For additional commands, e-mail: batik-users-help@xml.apache.org
>> >> >>
>> >> >> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail:
>> batik-users-unsubscribe@xml.apache.org >> For >> additional
>> commands, e-mail: batik-users-help@xml.apache.org
>> >>
GWJ> ---------------------------------------------------------------------
GWJ> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
GWJ> For additional commands, e-mail: batik-users-help@xml.apache.org
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
>> For >> additional commands, e-mail: batik-users-help@xml.apache.org
>>
GWJ> ---------------------------------------------------------------------
GWJ> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
GWJ> For additional commands, e-mail: batik-users-help@xml.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org For
>> additional commands, e-mail: batik-users-help@xml.apache.org
GWJ> ---------------------------------------------------------------------
GWJ> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
GWJ> For additional commands, e-mail: batik-users-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: Layering multiple SVG images
Posted by "G. Wade Johnson" <wa...@abbnm.com>.
I panned around all over the place with no update of the images. I even
panned far enough to move the image off the canvas, but when I brought
it back the images weren't updated.
I take it that this is not expected?
G. Wade
Thomas E Deweese wrote:
>
> >>>>> "GWJ" == G Wade Johnson <wa...@abbnm.com> 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 <wa...@abbnm.com> 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 <wa...@abbnm.com> 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 <wa...@abbnm.com>
> >> 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: >> >>
> >> batik-users-unsubscribe@xml.apache.org > GWJ> For additional >> >>
> >> commands, e-mail: batik-users-help@xml.apache.org
> >> >> >> >
> >> >> >> > ---------------------------------------------------------------------
> >> >> >> > To unsubscribe, e-mail:
> >> batik-users-unsubscribe@xml.apache.org >> > >> For additional
> >> commands, e-mail: >> batik-users-help@xml.apache.org
> >> >> >>
> >> >> >> ---------------------------------------------------------------------
> >> >> >> To unsubscribe, e-mail:
> >> batik-users-unsubscribe@xml.apache.org >> For >> additional
> >> commands, e-mail: batik-users-help@xml.apache.org
> >> >>
> GWJ> ---------------------------------------------------------------------
> GWJ> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
> GWJ> For additional commands, e-mail: batik-users-help@xml.apache.org
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
> >> For >> additional commands, e-mail: batik-users-help@xml.apache.org
> >>
> GWJ> ---------------------------------------------------------------------
> GWJ> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
> GWJ> For additional commands, e-mail: batik-users-help@xml.apache.org
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org For
> >> additional commands, e-mail: batik-users-help@xml.apache.org
>
> GWJ> ---------------------------------------------------------------------
> GWJ> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
> GWJ> For additional commands, e-mail: batik-users-help@xml.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-users-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: Layering multiple SVG images
Posted by Thomas E Deweese <th...@kodak.com>.
>>>>> "GWJ" == G Wade Johnson <wa...@abbnm.com> 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 <wa...@abbnm.com> 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 <wa...@abbnm.com> 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 <wa...@abbnm.com>
>> 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: >> >>
>> batik-users-unsubscribe@xml.apache.org > GWJ> For additional >> >>
>> commands, e-mail: batik-users-help@xml.apache.org
>> >> >> >
>> >> >> > ---------------------------------------------------------------------
>> >> >> > To unsubscribe, e-mail:
>> batik-users-unsubscribe@xml.apache.org >> > >> For additional
>> commands, e-mail: >> batik-users-help@xml.apache.org
>> >> >>
>> >> >> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail:
>> batik-users-unsubscribe@xml.apache.org >> For >> additional
>> commands, e-mail: batik-users-help@xml.apache.org
>> >>
GWJ> ---------------------------------------------------------------------
GWJ> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
GWJ> For additional commands, e-mail: batik-users-help@xml.apache.org
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
>> For >> additional commands, e-mail: batik-users-help@xml.apache.org
>>
GWJ> ---------------------------------------------------------------------
GWJ> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
GWJ> For additional commands, e-mail: batik-users-help@xml.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org For
>> additional commands, e-mail: batik-users-help@xml.apache.org
GWJ> ---------------------------------------------------------------------
GWJ> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
GWJ> For additional commands, e-mail: batik-users-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: Layering multiple SVG images
Posted by "G. Wade Johnson" <wa...@abbnm.com>.
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 <wa...@abbnm.com> 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 <wa...@abbnm.com> 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 <wa...@abbnm.com> 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: >>
> >> batik-users-unsubscribe@xml.apache.org > GWJ> For additional >>
> >> commands, e-mail: batik-users-help@xml.apache.org
> >> >> >
> >> >> > ---------------------------------------------------------------------
> >> >> > To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
> >> > >> For additional commands, e-mail:
> >> batik-users-help@xml.apache.org
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
> >> For >> additional commands, e-mail: batik-users-help@xml.apache.org
> >>
> GWJ> ---------------------------------------------------------------------
> GWJ> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
> GWJ> For additional commands, e-mail: batik-users-help@xml.apache.org
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org For
> >> additional commands, e-mail: batik-users-help@xml.apache.org
>
> GWJ> ---------------------------------------------------------------------
> GWJ> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
> GWJ> For additional commands, e-mail: batik-users-help@xml.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-users-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: Layering multiple SVG images
Posted by Thomas E Deweese <th...@kodak.com>.
>>>>> "GWJ" == G Wade Johnson <wa...@abbnm.com> 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 <wa...@abbnm.com> 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 <wa...@abbnm.com> 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: >>
>> batik-users-unsubscribe@xml.apache.org > GWJ> For additional >>
>> commands, e-mail: batik-users-help@xml.apache.org
>> >> >
>> >> > ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
>> > >> For additional commands, e-mail:
>> batik-users-help@xml.apache.org
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
>> For >> additional commands, e-mail: batik-users-help@xml.apache.org
>>
GWJ> ---------------------------------------------------------------------
GWJ> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
GWJ> For additional commands, e-mail: batik-users-help@xml.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org For
>> additional commands, e-mail: batik-users-help@xml.apache.org
GWJ> ---------------------------------------------------------------------
GWJ> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
GWJ> For additional commands, e-mail: batik-users-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: Layering multiple SVG images
Posted by "G. Wade Johnson" <wa...@abbnm.com>.
Thomas,
Thanks for your help on this so far.
I've modified SVGImageElementBridge to give me a getReferencedDocument()
method. Now, when I access what I thought was the Bridge for each
<image/> I get null as the document. I have proven to myself that the
member data is set correctly, so I assume that I'm not getting the
Bridge correctly.
How's the "right" way to get the Bridge associated with an Element?
G. Wade
Thomas E Deweese wrote:
>
> >>>>> "GWJ" == G Wade Johnson <wa...@abbnm.com> 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 <wa...@abbnm.com> 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:
> >> batik-users-unsubscribe@xml.apache.org > GWJ> For additional
> >> commands, e-mail: batik-users-help@xml.apache.org
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org >
> >> For additional commands, e-mail: batik-users-help@xml.apache.org
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org For
> >> additional commands, e-mail: batik-users-help@xml.apache.org
>
> GWJ> ---------------------------------------------------------------------
> GWJ> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
> GWJ> For additional commands, e-mail: batik-users-help@xml.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-users-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: Layering multiple SVG images
Posted by Thomas E Deweese <th...@kodak.com>.
>>>>> "GWJ" == G Wade Johnson <wa...@abbnm.com> 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 <wa...@abbnm.com> 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:
>> batik-users-unsubscribe@xml.apache.org > GWJ> For additional
>> commands, e-mail: batik-users-help@xml.apache.org
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org >
>> For additional commands, e-mail: batik-users-help@xml.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org For
>> additional commands, e-mail: batik-users-help@xml.apache.org
GWJ> ---------------------------------------------------------------------
GWJ> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
GWJ> For additional commands, e-mail: batik-users-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: Layering multiple SVG images
Posted by "G. Wade Johnson" <wa...@abbnm.com>.
Thomas,
I've been working on the SVGOMImageElement trick. I finally worked my
way down to getting the SVGImageElementBridge object associated with
each image in the SVG file. So far so good.
Unfortunately, the imgDocument field in the SVGImageElementBridge is
protected. I even tried to derive a class from SVGImageElementBridge
to get access and can't. Any ideas or have I run down the wrong trail?
G. Wade
"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 <wa...@abbnm.com> 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: batik-users-unsubscribe@xml.apache.org
> > GWJ> For additional commands, e-mail: batik-users-help@xml.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
> > For additional commands, e-mail: batik-users-help@xml.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-users-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: Layering multiple SVG images
Posted by "G. Wade Johnson" <wa...@abbnm.com>.
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 <wa...@abbnm.com> 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: batik-users-unsubscribe@xml.apache.org
> GWJ> For additional commands, e-mail: batik-users-help@xml.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-users-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
RE: Layering multiple SVG images
Posted by Thomas E Deweese <th...@kodak.com>.
>>>>> "GWJ" == G Wade Johnson <wa...@abbnm.com> 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: batik-users-unsubscribe@xml.apache.org
GWJ> For additional commands, e-mail: batik-users-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org