# Embedding plain SVG results in incorrect rendering **URL:** \ **Category:** Ignition\ **Tags:** perspective, ignition81\ **Created:** [February 4, 2022, 7:50pm UTC](https://forum.inductiveautomation.com/t/embedding-plain-svg-results-in-incorrect-rendering/55778 "2022-02-04T19:50:08Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![thewebpleb](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/thewebpleb/32/27415_2.png) [@thewebpleb](https://forum.inductiveautomation.com/u/thewebpleb)\ **Post date:** [February 4, 2022, 7:50pm UTC](https://forum.inductiveautomation.com/t/embedding-plain-svg-results-in-incorrect-rendering/55778/1 "2022-02-04T19:50:08Z")
Hi all, I’m working on a very simple SVG that represents 4 states of a machine: manual, auto, off and fault. I created a simple SVG in Inkscape, saved it as a plain SVG, and then dragged it over into the Perspective workspace. When I drop it in the workspace, I get a message ```auto This SVG image contains unsupported elements and may not render correctly when embedded. ``` Indeed, when I embed the SVG into a Perspective view, it looks different than when I open the plain SVG in Inkscape or Firefox. See below: ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/2/3/23efa310a470ba4f83862153d7de172c2af28b5f.png) ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/2/8/287018f3c48098917249d7492abc888143f18789.png) It looks like any gradients I applied aren’t being recognized by the designer. Why is that? This isn’t a deal breaker, I just want to understand what will and won’t be visible in the designer so I don’t waste time drawing something complicated that then won’t work like I want it to. What are unsupported elements? Is there a list of them? By the way, I can see the gradient when I drill into the SVG elements: ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/5/e/5e2d89fd1b19ec3a97b027eaa08d0ac44b3471e2.png) Here is the value of `gradientTransform`: ```json matrix(1.1716836,0,0,1.0252377,-0.06658026,-2.2651098) ``` Thank you all in advance! ---
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [February 4, 2022, 8:03pm UTC](https://forum.inductiveautomation.com/t/embedding-plain-svg-results-in-incorrect-rendering/55778/2 "2022-02-04T20:03:05Z")
The short version: The SVG spec is _immense_. Really, truly, ridiculously immense. We employ some extremely limited parsing when you drop an SVG in and choose to embed it. If there’s anything in the SVG we don’t recognize, we don’t _reject_ it - we just don’t assign it any meaning in the output. For _some_ things, that might be plausible to change on our side. For more exotic SVG features, it’ll probably never happen when embedding in this way; instead, just leave your SVG intact and display it as an image; in that case we don’t know or care about the contents of your SVG, and it’s up to the browser to render it correctly. ---
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [February 4, 2022, 8:04pm UTC](https://forum.inductiveautomation.com/t/embedding-plain-svg-results-in-incorrect-rendering/55778/3 "2022-02-04T20:04:03Z")
And having looked into it since it sounded familiar - we do in fact have a ticket in place to expand our SVG parsing and gradients are mentioned on that ticket. ---
**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 19, 2022, 8:27pm UTC](https://forum.inductiveautomation.com/t/embedding-plain-svg-results-in-incorrect-rendering/55778/4 "2022-09-19T20:27:03Z")
I had similar problems and you have an official response that explains what’s happening. I just wanted to add that @nminchin gave a really good tip to make sure you save your SVGs as optimized SVG in Inkscape. It makes the SVG a lot smaller which greatly improves performance when you have a lot of instances of your SVGs on a screen. For now I have been embedding my less detailed SVGs and loading the more detailed ones into image library. If you save them as optimized SVG they are very small and Ignition can handle them just fine at runtime. I tested 780 instances of one of my valve SVGs with them all bound to the same tag and it was fast using image library to swap what image is loaded to represent a state change. I have found that animating color using the fill hue feature often distorts SVGs so I only use that on simple svgs. In my case a hue wouldn’t work anyway because I’m animating flow path in a sanitary divert valve so the parts of the valve I’m animating are dynamic. ---
**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 19, 2022, 8:30pm UTC](https://forum.inductiveautomation.com/t/embedding-plain-svg-results-in-incorrect-rendering/55778/5 "2022-09-19T20:30:41Z")
> [@Steve\_Laubach](#): > > animating color using the fill hue feature often distorts S I'm fairly sure when the tint is changed, the SVG is rasterised, making it pixelated. I would never use tint on image library SVGs