Perspective SVG import handling

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

image

<svg xmlns="http://www.w3.org/2000/svg" 
  xmlns:xlink="http://www.w3.org/1999/xlink" width="300" height="300">
  <defs>
    <filter id='inset' x='-50%' y='-50%' width='200%' height='200%'>
      <!--outside-stroke-->
      <feFlood flood-color="red" result="outside-color"/>
      <feMorphology in="SourceAlpha" operator="dilate" radius="2"/>
      <feComposite in="outside-color" operator="in" result="outside-stroke"/>
      <!--inside-stroke-->
      <feFlood flood-color="blue" result="inside-color"/>
      <feComposite in2="SourceAlpha" operator="in" result="inside-stroke"/>
      <!--fill-area-->
      <feMorphology in="SourceAlpha" operator="erode" radius="2"/>
      <feComposite in="SourceGraphic" operator="in" result="fill-area"/>
      <!--merge graphics-->
      <feMerge>
        <feMergeNode in="outside-stroke"/>
        <feMergeNode in="inside-stroke"/>
        <feMergeNode in="fill-area"/>
      </feMerge>
    </filter>
  </defs>
  <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
  l2.5-0.3l4,3.4l12.3,2.4l-4.3,8.9l-1.1,9.1l-2.4,2.2l-3.9-1.2l0.3,3.2l-6.3,7l-0.1,5.6l4.1-1.9l2.9,5.4L121,84l2.5,4.6l-3,3.7
  l2.2,9.3l4.6,1.5l-1,5.1l-7.8,6.6l-16.9-3.2l-12.5,3.8l-1,7l-9.9,1.5l-9.6-5.3l-3.1,2.5l-15.8-5.3l-3.4-4.6l4.4-7.1l1.6-24.1
  l-8.8-13l-6.3-6.4l-13.1-4.9l-0.9-9.4l11.1-2.8L48.9,47l-2.7-14.8l8.1,5.7l20-10.3l2.6-11l7.5-2.8l1.3,4.8l4,0.2L93.5,24.2z"
fill="#00ffff" filter="url(#inset)"/>
  </g>
</svg>
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!

2 Likes


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

3 Likes

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.

Fantastic!

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.

This effort was merged today and should be available in tonight’s nightly build.

I’m going to leave this forum post open for requests which are NOT accounted for with this effort; we’ll try to work on future svgs in the Drawing Editor effort.

4 Likes

You can hide it with

style: display: none

image

1 Like

I loaded the nightly build on a VM and tested all of the SVGs in my library as embedded SVGs.

All of them rendered correctly. I haven’t messed around with animations yet or anything like that but it looks workable.

I tried that but put it in the wrong place by accident. I just checked my “test” and see what I did. Thanks.

1 Like