Improved SVG Importing & Rendering, and Convert To Drawing

Ignition Early Access
1

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) :tada:

Here is an example of an SVG that didn’t work previous, but now does
d744bc59-0257-40b3-aac5-450265958e14

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

20 Likes
3

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.

3 Likes
4

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

3 Likes
5

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.

2 Likes
6

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”

This might also solve some problems with loading. Here is a public facing (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.

7

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
5 Likes
8

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.

9

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.

10

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

1 Like
11

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.

1 Like
12

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.

1 Like
13

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

1 Like
14

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.

15

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

2 Likes
17

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

1 Like
18

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

2 Likes
19

Seems like a job for the already-existing Alt :slight_smile:

2 Likes
20

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

svg
image

html
image

1 Like
21

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

1 Like