Perspective SVG import handling

We’re currently working on improving how SVGs are imported/embedded/rendered in Perspective and we’re looking for some insight into SVG files which have not historically worked for users.

To be clear, SVGs are incredibly complicated and there’s no way we can make all SVGs magically work - but we’re going to try our hardest to make sure we’re not preventing SVGS from working for no valid reason. To this end, we’d like to solicit these forums for SVG files you might have attempted to use previously but which rendered incorrectly in some way, or which previously warned you about invalid tags. Please supply (upload) your SVG in this thread with a picture of what the SVG is supposed to look like, or you can message me directly if you’d prefer not to publicly share the resource and accompanying picture. This thread will eventually be removed as testing is completed.


Dont forget to add events that reference the name/id of the svg element(group) clicked :stuck_out_tongue:


Could you clarify what you’re looking for, @victordcq ?

Basically if a user clicks on a portion of an SVG to handle the event somehow. For example, if the SVG is 10 circles, clicking on each circle would open a specific popup, or typical popup with specifc parameters.

That is NOT something we’re looking to address with this effort. What you’re describing could potentially be addressed as part of the greater Drawing Editor effort. This effort is strictly restricted to better import handling of svgs, display of those svgs, and converting some components to their constituent svg pieces.

Understand. Perhaps @victordcq was referring to something else.

Since you brought it up...

Can you elaborate?

@victordcq has created a module to catch events. I typically just stack a component, or embed individual SVGs, but that can impact performance.

Are there any plans to catch events?

I’m glad to see there is a lot of effort on making SVGs work better in Ignition. I really don’t expect it to be a replacement of Inkscape but to just show them correctly.

I also know that there will be or there is some effort into adding SVG drawing tools. Some basic drawing would be nice but I insist that a full drawing tool will be better handled in other programs designed for it

Better support for gradients is about the only thing I can really think of.

Last I checked, importing them sometimes works and sometimes doesn’t. I’ll have to see if I can work up an example tomorrow.

1 Like

@lrose , if you can find some examples which don’t currently work well, please send them along so that I can verify they’re working with the updated approach. I’ve already verified gradients through some svgs attached to active Support tickets:

The only experience I have with SVGs was creating a pretty complex process visualization graphic and importing that into a Perspective view. What would be nice is if there was an automatic process of creating bindings to certain properties of the SVG. In my case, I wanted to bind the fill and stroke properties of a ton of shapes (to indicate state) and every time I made changes in Inkscape and reimported the SVG, I’d need to go through and recreate the bindings, which got very tedious (and made me greatly minimize the number of edits I made). I’m not sure how automating this would work, maybe parsing for a certain string of characters, kind of like how style classes have .psc- prepended to them.

Yeah that is what i ment. But i indeed have a module made for this myself, it's kinda clucky xD

I got some svg feature i tried to use here before that didnt work... filters


<svg xmlns="" 
  xmlns:xlink="" width="300" height="300">
    <filter id='inset' x='-50%' y='-50%' width='200%' height='200%'>
      <feFlood flood-color="red" result="outside-color"/>
      <feMorphology in="SourceAlpha" operator="dilate" radius="2"/>
      <feComposite in="outside-color" operator="in" result="outside-stroke"/>
      <feFlood flood-color="blue" result="inside-color"/>
      <feComposite in2="SourceAlpha" operator="in" result="inside-stroke"/>
      <feMorphology in="SourceAlpha" operator="erode" radius="2"/>
      <feComposite in="SourceGraphic" operator="in" result="fill-area"/>
      <!--merge graphics-->
        <feMergeNode in="outside-stroke"/>
        <feMergeNode in="inside-stroke"/>
        <feMergeNode in="fill-area"/>
  <g transform="scale(2)">
    <path class="st0" d="M144.7,126.2l-2.8,8.8l-3.9-2.3l-2-7.7l1.7-4.3l5.5-4.4L144.7,126.2z M93.5,24.2l6,6.3l4.4-1l7.5,6l1.9,1.1
fill="#00ffff" filter="url(#inset)"/>
1 Like

Thank you everyone! I checked these examples against the development work and we’ll need a couple of more tweaks to get these working. We’ll see what we can do!


We were able accommodate the provided svg after some minor tweaks.


Last call on problematic svgs! Anything we can’t get working here will have to wait until the Drawing Editor is completed.

This is exciting. Do you have an ETA on when these changes are likely to make it to a live build?

These changes will hopefully enter a nightly build sometime this week.


Thank you.

1 Like

I’m not sure if this is considered related but visibility properties are not recognized on embedded SVGs so you can’t embed an SVG and adjust visibility on segments of the SVG using scripts + custom properties added to the SVG after you embed them.

Imagine a scenario where you have an overhead valve that can support up to 4 directions for ports. It would be good to be able to create a single SVG and manipulate the visibility of ports in Ignition.

I do this already with SVGs referenced from the image library where I have built a structure containing every possible valve orientation as individual images (not ideal) and then manipulate which SVG is loaded using custom properties on the perspective image control (N, S, E and W). At design time I can manipulate the check boxes (custom properties) to change the indirect pathing to load the correct image from the image library. This allows me to build a valve cluster by copy/pasting my image control for each valve in a valve cluster and tweaking the check boxes to adjust the port orientation.

The main time I use this overhead valve symbol is with valve clusters for CIP systems. Here’s a screenshot to kind of give you an idea of what I’m talking about. I’ve also included an SVG with each port “group” labeled. That’s the part I would animate visibility on based on the custom properties.
Overhead Valve
Overhead Valve

I’m not going to hold my breath on this but I figure it doesn’t hurt to ask :slight_smile:

We’ll need to look into that later because that’s a function of how svgs operate or are rendered, not how they’re imported/embedded.