# Improved SVG Importing & Rendering, and Convert To Drawing

**URL:** <https://forum.inductiveautomation.com/t/improved-svg-importing-rendering-and-convert-to-drawing/64504>\
**Category:** Ignition Early Access\
**Created:** [September 26, 2022, 8:38pm UTC](https://forum.inductiveautomation.com/t/improved-svg-importing-rendering-and-convert-to-drawing/64504 "2022-09-26T20:38:45Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![mperkins](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/mperkins/32/71722_2.png) [@mperkins](https://forum.inductiveautomation.com/u/mperkins)\
**Post date:** [September 26, 2022, 8:38pm UTC](https://forum.inductiveautomation.com/t/improved-svg-importing-rendering-and-convert-to-drawing/64504/1 "2022-09-26T20:38:45Z")

</div>

_ **Improved SVG Importing & Rendering** _  
In the next nightly, the SVG Importer and Drawing Component renderer have been greatly improved. These changes are foundational for the upcoming drawing editor. SVGs that didn’t work previously will _likely_ work, so long as they’re imported and rendered with the latest nightly. SVGs imported using a previous version of Ignition will render the same as they did before.

This isn’t a guarantee that _all_ SVG elements will import and render correctly, but most should.

In particular the following SVG elements received development attention.

- animate
- circle
- clippath
- defs
- ellipse
- filter
- feblend
- fecolormatrix
- fecomposite
- feconvolvematrix
- fedisplacementmap
- fedropshadow
- feflood
- fegaussianblur
- feimage
- femerge
- feoffset
- femorphology
- fespecularlighting
- feturbulence
- fetile
- g
- line
- lineargradient
- marker
- mask
- pattern
- path
- polygon
- polyline
- radialgradient
- rect
- svg(embedded in the root SVG)
- text
- tspan
- textpath
- tspan
- use
- symbol

Many of the filters in particular rely on DOM Ids- `which should be unique`. To that end, the importer automatically imports them as is, and then `the renderer automatically prefixes them to ensure that they are unique`. This includes things like `filter="url(#my-id)"` or `fill="url(#gradient)`🎉

Here is an example of an SVG that didn’t work previous, but now does  
 ![d744bc59-0257-40b3-aac5-450265958e14](https://us1.discourse-cdn.com/inductiveautomation/original/3X/0/1/01328ead659f0887e6987df6576e6355a5475ac1.gif)

* * *

_ **Convert to Drawing** _  
There is a new item added to the right click menu for a subset of SVG based components (and pipes), “convert to drawing”. It will convert the component to a drawing- minus an bindings as those bindings don’t correspond 1 to 1 with Drawing props, and it would be incredibly difficult to do so. This allows for fine control of individual elements- including the ability to add bindings to individual pieces of a component- now a Drawing.

**Affected Components**

- Cylindrical Tank
- Icon
- Linear Scale
- Moving Analog Indicator
- Sparkline
- Thermometer
- All Symbols including Motor, Pump, Sensor, Valve, and Vessel
- Coordinate Container (containing pipes) - All pipes within the container will be converted to a single drawing

![5e853529-2ae6-44f8-ac07-48cb6f5fb73e](https://us1.discourse-cdn.com/inductiveautomation/original/3X/a/6/a6afc7528c69b07866d14e06789b13b5e8267561.gif)

---

<div class="post-metadata">

**Author:** ![mperkins](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/mperkins/32/71722_2.png) [@mperkins](https://forum.inductiveautomation.com/u/mperkins)\
**Post date:** [September 26, 2022, 8:39pm UTC](https://forum.inductiveautomation.com/t/improved-svg-importing-rendering-and-convert-to-drawing/64504/2 "2022-09-26T20:39:00Z")

</div>



---

<div class="post-metadata">

**Author:** ![kgamble](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kgamble/32/8019_2.png) [@kgamble](https://forum.inductiveautomation.com/u/kgamble)\
**Post date:** [September 27, 2022, 2:29am UTC](https://forum.inductiveautomation.com/t/improved-svg-importing-rendering-and-convert-to-drawing/64504/3 "2022-09-27T02:29:48Z")

</div>

> [@mperkins](#):
>
> - Coordinate Container (containing pipes) - All pipes within the container will be converted to a single drawing

Hear me out, what about alllll of the affected components in the coordinate container being flattened into one SVG? Could really help the way that heavy P&ID style screens are rendered.

---

<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:** [September 27, 2022, 3:31am UTC](https://forum.inductiveautomation.com/t/improved-svg-importing-rendering-and-convert-to-drawing/64504/4 "2022-09-27T03:31:19Z")

</div>

Looks good!  
Can there also be a function to copy the Drawing to SVG XML to the clipboard / save as an SVG file?

---

<div class="post-metadata">

**Author:** ![mperkins](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/mperkins/32/71722_2.png) [@mperkins](https://forum.inductiveautomation.com/u/mperkins)\
**Post date:** [September 27, 2022, 2:55pm UTC](https://forum.inductiveautomation.com/t/improved-svg-importing-rendering-and-convert-to-drawing/64504/5 "2022-09-27T14:55:23Z")

</div>

That’s not a use case I considered, but it is a possibility. Are you envisioning that only the direct children of the coordinate container be affected? (it’d be somewhat difficult to have grand child SVGs all line up in the expected location)

Or maybe a function where you select multiple Drawing Components and combined the selected SVGs, rather than all children.

---

<div class="post-metadata">

**Author:** ![kgamble](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kgamble/32/8019_2.png) [@kgamble](https://forum.inductiveautomation.com/u/kgamble)\
**Post date:** [September 27, 2022, 3:01pm UTC](https://forum.inductiveautomation.com/t/improved-svg-importing-rendering-and-convert-to-drawing/64504/6 "2022-09-27T15:01:51Z")

</div>

> [@mperkins](#):
>
> it’d be somewhat difficult to have grand child SVGs all line up in the expected location

Yeah I wasn’t thinking this, but an explicitly “Drawing container” could enable doing this but still leveraging templates drawings. Or maybe a setting on coordinate containers for something like “pre-render with parent”

> [@mperkins](#):
>
> Or maybe a function where you select multiple Drawing Components and combined the selected SVGs,

This might also solve some problems with loading. [Here is a public facing](https://demo.bwdesigngroup.com/data/perspective/client/PANDID_TEST) (although very broken) P&ID that helps see the rendering problems without a GPU. If this type of P&ID could be flattened it would all show up as one unit, instead of slowly each different svg churning to life.

---

<div class="post-metadata">

**Author:** ![mperkins](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/mperkins/32/71722_2.png) [@mperkins](https://forum.inductiveautomation.com/u/mperkins)\
**Post date:** [September 27, 2022, 3:04pm UTC](https://forum.inductiveautomation.com/t/improved-svg-importing-rendering-and-convert-to-drawing/64504/7 "2022-09-27T15:04:59Z")

</div>

I like that suggestion, it’d allow editing in an outside Drawing Editor, and it wouldn’t be too hard to implement. Though the need would be somewhat obviated when Perspective’s Drawing Editor is complete, it’s still nice to have a choice.

* * *

_ **On the technical side** _  
Currently convert to drawing works like this:

1. Component Props (Say Sparkline Component)
2. Perspective Component being rendered
3. SVG being rendered in the DOM
4. Resulting SVG being read from the DOM
5. SVG being converted to Drawing Component Props

Save Drawing (or even SVG based component) as SVG would work like this:

1. Component Props (Say Sparkline Component)
2. Perspective Component being rendered
3. SVG being rendered in the DOM
4. Resulting SVG being read from the DOM
5. SVG saved as a file

---

<div class="post-metadata">

**Author:** ![nader.chinichian](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/nader.chinichian/32/9261_2.png) [@nader.chinichian](https://forum.inductiveautomation.com/u/nader.chinichian)\
**Post date:** [September 28, 2022, 9:38am UTC](https://forum.inductiveautomation.com/t/improved-svg-importing-rendering-and-convert-to-drawing/64504/8 "2022-09-28T09:38:45Z")

</div>

Can you add an option to disable prefix ti SVG IDs.  
As I assign Id in the inkscape and use those Id in my python code to make elements dynamic. Auto prefixing broke my logic.  
Also inkscape prevent duplicate Id. So they’re is no need for that.

Do you have any plan to add click on element on SVG expand automatically elements tree props?  
Some thing like VISON. Now if I need to edit an element it is nightmare to find it from elements tree manually.

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [September 28, 2022, 12:44pm UTC](https://forum.inductiveautomation.com/t/improved-svg-importing-rendering-and-convert-to-drawing/64504/9 "2022-09-28T12:44:56Z")

</div>

> [@nader.chinichian](#):
>
> Also inkscape prevent duplicate Id. So they’re is no need for that.

ID's have to be unique throughout the whole webpage--prefixing prevents a clash between yours and IA's, not just within a single SVG.

---

<div class="post-metadata">

**Author:** ![nader.chinichian](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/nader.chinichian/32/9261_2.png) [@nader.chinichian](https://forum.inductiveautomation.com/u/nader.chinichian)\
**Post date:** [September 28, 2022, 1:07pm UTC](https://forum.inductiveautomation.com/t/improved-svg-importing-rendering-and-convert-to-drawing/64504/10 "2022-09-28T13:07:05Z")

</div>

I think you miss understand me. There are some name properties in each element in SVG which is the Id of drawing tools. There are always unique drawing tools. So there is no conflict with domId.  
 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/0/6/06612165411a7718e8d23efd035c6d7a948c9461.png)

---

<div class="post-metadata">

**Author:** ![nader.chinichian](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/nader.chinichian/32/9261_2.png) [@nader.chinichian](https://forum.inductiveautomation.com/u/nader.chinichian)\
**Post date:** [September 28, 2022, 1:11pm UTC](https://forum.inductiveautomation.com/t/improved-svg-importing-rendering-and-convert-to-drawing/64504/11 "2022-09-28T13:11:13Z")

</div>

As this topic is also related to pipe tools. I’d like to add the following items which miss in piping tools right now.

Piping Tools Missing Features:  
1 - Adding keyboard shortcut for changing between piping mode and component mode.  
2 - Dragging the mouse over all components and pipes causes the user can move all objects together. Now he can select only components.  
3 - Support arrow keys for changing pipeline position. (both fine and normal jump)  
4 - Disable/Enable option for pipeline snap in editing mode. Now it is crazy to work with this snap-to-object system.  
5 - Allow for closed loop pipes.  
6 - Add a border radius to the edge of the pipeline  
7 - Add dash setting for the pipe so we can have custom space like dash-array. (ex: 2 5, 1 3)  
8 - dedicated style for each pipe segment.  
9 - Option to change arrow direction for each segment. In star topology pipes the arrow direction doesn’t show the correct direction.  
10 - Add more Line variation options based on the standard P&ID.

---

<div class="post-metadata">

**Author:** ![Steve\_Laubach](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/steve_laubach/32/60900_2.png) [@Steve\_Laubach](https://forum.inductiveautomation.com/u/Steve_Laubach)\
**Post date:** [September 28, 2022, 2:00pm UTC](https://forum.inductiveautomation.com/t/improved-svg-importing-rendering-and-convert-to-drawing/64504/12 "2022-09-28T14:00:45Z")

</div>

I tested my current SVG symbol library on this nightly build and everything loaded correctly.

I really like the direction you’re going with symbols and drawing tools. It really gives us a lot of flexibility with building systems.

---

<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:** [September 28, 2022, 2:46pm UTC](https://forum.inductiveautomation.com/t/improved-svg-importing-rendering-and-convert-to-drawing/64504/13 "2022-09-28T14:46:15Z")

</div>

> [@pturmel](#):
>
> ID’s have to be unique throughout the whole webpage

Welh thats actually not really required. Everything will still work with multiple id's, its really bad practice though. And most scripts will expect there to be only one element with an id so they will not search for the others, eventho its possible to look for all

---

<div class="post-metadata">

**Author:** ![mperkins](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/mperkins/32/71722_2.png) [@mperkins](https://forum.inductiveautomation.com/u/mperkins)\
**Post date:** [September 28, 2022, 3:31pm UTC](https://forum.inductiveautomation.com/t/improved-svg-importing-rendering-and-convert-to-drawing/64504/14 "2022-09-28T15:31:43Z")

</div>

> Can you add an option to disable prefix ti SVG IDs.

would a Drawing Component level prop be sufficient? As in disabling auto-prefixing for the entire drawing. It gets complicated to selectively do that for elements, because elements may be referred to by other elements(filters, fill, masking, etc), and those references would also have to not be prefixed.

> Now if I need to edit an element it is nightmare to find it from elements tree manually.

I feel your pain. Modifying a prop tree for a drawing IS a nightmare. Development resources are being put into implementing the Drawing Editor which should improve things, but certainly there is room for improvement in the property tree.

---

<div class="post-metadata">

**Author:** ![mperkins](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/mperkins/32/71722_2.png) [@mperkins](https://forum.inductiveautomation.com/u/mperkins)\
**Post date:** [September 28, 2022, 4:01pm UTC](https://forum.inductiveautomation.com/t/improved-svg-importing-rendering-and-convert-to-drawing/64504/15 "2022-09-28T16:01:49Z")

</div>

> 1 - Adding keyboard shortcut for changing between piping mode and component mode.  
> 2 - Dragging the mouse over all components and pipes causes the user can move all objects together. Now he can select only components.

I believe the plan is to combine the modes so that pipes and components can be interacted together.

> 3 - Support arrow keys for changing pipeline position. (both fine and normal jump)

Yes, I found it frustrating to fine tune pipe positions without it

> 4 - Disable/Enable option for pipeline snap in editing mode. Now it is crazy to work with this snap-to-object system.

Yes, I did notice this while interacting with a customer's view the other day- there's just so many positions (components and pipes) that a given pipe can snap to that it becomes unworkable. I believe this is also an area that the rest of Perspective could work on.

> 5 - Allow for closed loop pipes.

Unlikely, the pipe data model is a tree, and while there are ways to make this work... it might be pretty opaque to anyone looking at the resulting property tree

> 6 - Add a border radius to the edge of the pipeline  
> 7 - Add dash setting for the pipe so we can have custom space like dash-array. (ex: 2 5, 1 3)  
> 10 - Add more Line variation options based on the standard P&ID.

seem like reasonable visual options

> 8 - dedicated style for each pipe segment.

We've avoided per pipe segment settings, but personally I'm for them. The props could be attached to connected point, ie props.pipes[0].connections[1].style would refer to the pipe segment between connection address [0] and [0,1]

> 9 - Option to change arrow direction for each segment. In star topology pipes the arrow direction doesn’t show the correct direction.

Would you mind giving a screenshot with some labels as to what you're trying to accomplish? It might be possible with the current implementation

---

<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:** [September 29, 2022, 3:37pm UTC](https://forum.inductiveautomation.com/t/improved-svg-importing-rendering-and-convert-to-drawing/64504/17 "2022-09-29T15:37:21Z")

</div>

> [@mperkins](#):
>
> I believe this is also an area that the rest of Perspective could work on.

There already is a solution for the rest of perspective though, if you hold Alt, snappings are turned off while you're dragging a component around

---

<div class="post-metadata">

**Author:** ![mperkins](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/mperkins/32/71722_2.png) [@mperkins](https://forum.inductiveautomation.com/u/mperkins)\
**Post date:** [September 30, 2022, 3:00pm UTC](https://forum.inductiveautomation.com/t/improved-svg-importing-rendering-and-convert-to-drawing/64504/18 "2022-09-30T15:00:05Z")

</div>

with pipes, you can hold "shift" for moving a single connection freely- _without_ the ortho behavior(moving other orthogonal connections) and _without_ snapping.

I'm thinking that there should be a modifier for moving a connection _with_ ortho and _without_ snapping

---

<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:** [September 30, 2022, 7:56pm UTC](https://forum.inductiveautomation.com/t/improved-svg-importing-rendering-and-convert-to-drawing/64504/19 "2022-09-30T19:56:37Z")

</div>

Seems like a job for the already-existing Alt 🙂

---

<div class="post-metadata">

**Author:** ![Sam\_Corbett](https://avatars.discourse-cdn.com/v4/letter/s/85f322/32.png) [@Sam\_Corbett](https://forum.inductiveautomation.com/u/Sam_Corbett)\
**Post date:** [October 14, 2022, 4:56am UTC](https://forum.inductiveautomation.com/t/improved-svg-importing-rendering-and-convert-to-drawing/64504/20 "2022-10-14T04:56:18Z")

</div>

> [@mperkins](#):
>
> pattern

Great to see greater SVG support, however I've just given this shot and it looks like the svg pattern type is incorrectly set as type 'marker' when svg is embedded  
See below  
Easily fixed by manually changing the def element type to 'pattern'

embedded import

 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/8/4/84d95d682ee9c69b22cffe774e8fe6084a30a37c.png)

svg  
 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/7/a/7a2fcf333cfab3e6109975969dfebe6931f9311d.png)

html

 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/c/9/c9ef53eff84fe9d7ff1df9be609ff1f2594f81cf.png)

---

<div class="post-metadata">

**Author:** ![mperkins](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/mperkins/32/71722_2.png) [@mperkins](https://forum.inductiveautomation.com/u/mperkins)\
**Post date:** [October 14, 2022, 2:47pm UTC](https://forum.inductiveautomation.com/t/improved-svg-importing-rendering-and-convert-to-drawing/64504/21 "2022-10-14T14:47:09Z")

</div>

Thank you for alerting me, I have reproduced the issue on my end and will file a bug ticket.

[Next page](https://forum.inductiveautomation.com/t/improved-svg-importing-rendering-and-convert-to-drawing/64504.md?page=2)
