# Making changes to embedded SVG in perspective

**URL:** <https://forum.inductiveautomation.com/t/making-changes-to-embedded-svg-in-perspective/71116>\
**Category:** Ignition\
**Tags:** perspective, ignition81\
**Created:** [March 15, 2023, 8:46pm UTC](https://forum.inductiveautomation.com/t/making-changes-to-embedded-svg-in-perspective/71116 "2023-03-15T20:46:01Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![Chris.Wyllie](https://avatars.discourse-cdn.com/v4/letter/c/5fc32e/32.png) [@Chris.Wyllie](https://forum.inductiveautomation.com/u/Chris.Wyllie)\
**Post date:** [March 15, 2023, 8:46pm UTC](https://forum.inductiveautomation.com/t/making-changes-to-embedded-svg-in-perspective/71116/1 "2023-03-15T20:46:01Z")

</div>

Hi Guys,

I am using perspective with SVG and I have found that embedding them to get access to binding elements is a huge help with the project I am currently working on.  
The SVG is created in inkscape from there I have 30+ bindings setup on the individual elements.

Here is the issue, there is a very good chance that when this project is reviewed by the client they will want changes to the SVG. Some of this chances I might be able to do by manipulating the elements but there is a good chance that I will need to go back to inkscape.

If I need to go back to inkscape for "major" changes the only way I can bring in the new changes is by deleting the existing embedded SVG but from what I can see this would also delete my bindings on that existing SVG.

The only way I can see to make this less impact full would be to:

- Breakup the SVG into smaller chunks so it minimises the amount of bindings I need to re-do when re-embedding
- Try to import most of the changes directly into the "elements" array

Is there anything I am missing?

I am sure the long awaited drawing tools will fix this issue?

---

<div class="post-metadata">

**Author:** ![Ryan\_Allen](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/ryan_allen/32/47013_2.png) [@Ryan\_Allen](https://forum.inductiveautomation.com/u/Ryan_Allen)\
**Post date:** [March 15, 2023, 9:15pm UTC](https://forum.inductiveautomation.com/t/making-changes-to-embedded-svg-in-perspective/71116/2 "2023-03-15T21:15:13Z")

</div>

I haven't done this myself, but I know Nader uses dynamic bindings based on the element ID which should solve this issue in theory

---

<div class="post-metadata">

**Author:** ![Chris.Wyllie](https://avatars.discourse-cdn.com/v4/letter/c/5fc32e/32.png) [@Chris.Wyllie](https://forum.inductiveautomation.com/u/Chris.Wyllie)\
**Post date:** [March 15, 2023, 10:03pm UTC](https://forum.inductiveautomation.com/t/making-changes-to-embedded-svg-in-perspective/71116/3 "2023-03-15T22:03:46Z")

</div>

Thanks Ryan,

I did some more searching based on this and found this post. Seems to answer my questions.  
Thanks.

> [@Perspective large and complex SVG animation tips please](https://forum.inductiveautomation.com/t/perspective-large-and-complex-svg-animation-tips-please/63526/25):
>
> I wonder if the difference with the embedded version is the stroke width (and maybe other parameters) either missing or the value (for example .5) is a string and you need to edit it to 0.5? [image]

---

<div class="post-metadata">

**Author:** ![Chris.Wyllie](https://avatars.discourse-cdn.com/v4/letter/c/5fc32e/32.png) [@Chris.Wyllie](https://forum.inductiveautomation.com/u/Chris.Wyllie)\
**Post date:** [March 16, 2023, 2:06am UTC](https://forum.inductiveautomation.com/t/making-changes-to-embedded-svg-in-perspective/71116/4 "2023-03-16T02:06:47Z")

</div>

For anyone reading this (including me) in the future this is how I ended up doing it. There are other ways that maybe better or more efficient.

For my case my SVG was being used in a template with a UDT so:

1. Created my SVG in inkscape making sure to give all the object I will interact with names (and Id's)
2. Created some custom properties on the root of the view template. The idea being these will be the "interface" to hold the script code (to run on property change); I can then just bind tags to these properties. If the SVG is deleted these props remain as they are on the root.
3. Right clicked on the property and added the code to transverse the SVG structure and change the property I wanted. In one of my cases the code looked like this:

```auto
	Debug = False
	if Debug: system.perspective.print("Starting")
	
	
	GroupName = "Alarm_Box"
	ElementName = "Alarm_indicator"
	ElementProperty = "fill"
	ElementSubProperty = "paint"
	
	#here is the logic for the new value of the property based off the tag value (currenValue)
	if currentValue.value:
		value = "#ff0000" #red
	else:
		value = "#00ff00" # green
	
	#Link to the SVG drawing elements
	SVG_Groups = self.getChild("ProtectionRelay").props.elements[1].elements
	
	#Find the group we are intrested in
	for SVG_Group in SVG_Groups:
		if Debug: system.perspective.print("Searching Group:"+ SVG_Group.name)
		
		if SVG_Group.name == GroupName:
			
			#Now search for the Element we want to edit
			SVG_Elements = SVG_Group.elements
			for SVG_Element in SVG_Elements:
				if Debug: system.perspective.print("Searching Elements:"+ SVG_Element.name)
				
				if SVG_Element.name == ElementName:
					if Debug: system.perspective.print("Found it")
					
					#Now we look for the property and sub property and update its value
					setattr(getattr(SVG_Element,ElementProperty),ElementSubProperty,value)
					
					if Debug: 
						test = getattr(getattr(SVG_Element,ElementProperty),ElementSubProperty)
						system.perspective.print("Read back: " + test)
						system.perspective.print("Attempted: " + value)
					
					# No need to search the rest of the elements
					break
			# No need to search the rest of the groups
			break

```

1. Now I can just bind my tags to the property I created on the root.

Now I can delete and re-import the SVG as much as I want provide I keep the group and element names the same.

Thanks to [nader.chinichian](https://forum.inductiveautomation.com/u/nader.chinichian) for the inspiration for this idea from this post:

> [@Perspective large and complex SVG animation tips please](https://forum.inductiveautomation.com/t/perspective-large-and-complex-svg-animation-tips-please/63526/19):
>
> So @victordcq has written a module to handle click events for SVG. I think the first idea @nader.chinichian had was to use scripting over bindings. If you use bindings and update the SVG, then you will most likely wipe out and break the bindings. Scripting wouldn’t have this limitation, plus using scripting potentially you could have all scripts in one location, depends on how you have things arranged and your needs. I am however a little confused on what he meant by creating own protocol and …

---

<div class="post-metadata">

**Author:** ![nminchin](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/nminchin/32/6911_2.png) [@nminchin](https://forum.inductiveautomation.com/u/nminchin)\
**Post date:** [March 22, 2023, 5:17am UTC](https://forum.inductiveautomation.com/t/making-changes-to-embedded-svg-in-perspective/71116/5 "2023-03-22T05:17:25Z")

</div>

You also give all of your elements meaningful ids and then reference the ids instead of structures. Then it doesn't matter where you move your elements, it'll always just work. This is how I believe Nader does it as well

---

<div class="post-metadata">

**Author:** ![mdemaris](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/mdemaris/32/54639_2.png) [@mdemaris](https://forum.inductiveautomation.com/u/mdemaris)\
**Post date:** [December 7, 2023, 1:27am UTC](https://forum.inductiveautomation.com/t/making-changes-to-embedded-svg-in-perspective/71116/6 "2023-12-07T01:27:49Z")

</div>

Chris,

where did you use this code to transverse the SVG structure?

---

<div class="post-metadata">

**Author:** ![Chris.Wyllie](https://avatars.discourse-cdn.com/v4/letter/c/5fc32e/32.png) [@Chris.Wyllie](https://forum.inductiveautomation.com/u/Chris.Wyllie)\
**Post date:** [December 11, 2023, 5:10am UTC](https://forum.inductiveautomation.com/t/making-changes-to-embedded-svg-in-perspective/71116/7 "2023-12-11T05:10:51Z")

</div>

It went through a few more iterations but I ended up deploying it as a function in the gateway scripting module.

This way I was able to call it from anywhere in my project as a single line of code and just pass it the path to the embedded SVG, name of the properties I wanted to change and the value to change it to.

---

<div class="post-metadata">

**Author:** ![brandon1](https://avatars.discourse-cdn.com/v4/letter/b/ea666f/32.png) [@brandon1](https://forum.inductiveautomation.com/u/brandon1)\
**Post date:** [December 11, 2023, 1:43pm UTC](https://forum.inductiveautomation.com/t/making-changes-to-embedded-svg-in-perspective/71116/8 "2023-12-11T13:43:16Z")

</div>

I wonder what the performance of this method is given that you are putting a script on every property change? My standard design philosophy would say this kind of solution should be avoided.

---

<div class="post-metadata">

**Author:** ![victordcq](https://avatars.discourse-cdn.com/v4/letter/v/f6c823/32.png) [@victordcq](https://forum.inductiveautomation.com/u/victordcq)\
**Post date:** [December 11, 2023, 2:42pm UTC](https://forum.inductiveautomation.com/t/making-changes-to-embedded-svg-in-perspective/71116/9 "2023-12-11T14:42:10Z")

</div>

It depends what has to be changed.  
Some changes requires this.  
For thinks like colors/animations i would suggest using css though, but that probably is harder if they change the image often

---

<div class="post-metadata">

**Author:** ![lrose](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/lrose/32/62724_2.png) [@lrose](https://forum.inductiveautomation.com/u/lrose)\
**Post date:** [December 11, 2023, 2:45pm UTC](https://forum.inductiveautomation.com/t/making-changes-to-embedded-svg-in-perspective/71116/10 "2023-12-11T14:45:43Z")

</div>

> [@brandon1](#):
>
> My standard design philosophy would say this kind of solution should be avoided.

I would agree with this sentiment.
