Optimize the SVG output

[kjbrum]

Is there any way to do something similar to what SVGO does to optimize the output SVG?

[meyerweb]

It’s a great question, and one I don’t have an answer to right now. Path-merging seems like the most promising avenue for optimization, especially given the most common uses cases for this script. If nothing else, we could add a note to the README pointing people to SVGO as a second step—first, convert from pixels; then, optimize with SVGO.

[kjbrum]

I agree, I was more curious if there was a way to do what SVGO does, in PHP? I'm asking because I'm working on a WordPress Plugin and the outputs are way to high, turning a 5kb GIF into a 600kb SVG. Thoughts?

[shshaw]

Regarding optimization, I made a Javascript version of this concept utilizing <canvas> and was able to cut down file size dramatically using <path> instead of <rect>.

My script outputs one <path> for each color with a stroke of that color and the d attribute populated with M[x],[y]h[line-length] in place of each <rect>. So two pixels of black at [0,1] would be <path stroke="#000" d="M0,1h2">. The x and y separator can be a comma or a space; in the script I use a space to help with line-wrapping. You can read more in-depth about the d attribute's syntax on Joni's Pocket Guide to Writing SVG.

Since SVG strokes start in the middle of a path, I offset the viewBox to 0 -0.5 [width] [height].

My script isn't optimized for vertical runs, but you could apply your same vertical or horizontal optimization by just changing the h to v to create a vertical line of that length, though you will need to add 0.5 to the x to accommodate the stroke origin.

Here's the Gmail 'bozo' gif from Joe's article run through my script, weighing only 1kb versus the original's 10kb.

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 -0.5 35 18.5" shape-rendering="crispEdges">
<path stroke="#e8eef7" d="M0 0h35M0 1h2M33 1h2M0 2h1M34 2h1M0 3h1M34 3h1M0 4h1M34 4h1M0 5h1M34 5h1M0 6h1M34 6h1M0 7h1M34 7h1M0 8h1M34 8h1M0 9h1M34 9h1M0 10h1M34 10h1M0 11h1M34 11h1M0 12h1M34 12h1M0 13h1M34 13h1M0 14h1M34 14h1M0 15h1M34 15h1M0 16h2M33 16h2M0 17h35" />
<path stroke="#cc0000" d="M2 1h31M1 2h33M1 3h33M1 4h33M1 5h6M8 5h26M1 6h6M8 6h26M1 7h6M8 7h26M1 8h6M10 8h4M16 8h3M22 8h3M27 8h7M1 9h6M8 9h2M11 9h2M14 9h2M17 9h4M22 9h2M25 9h2M28 9h6M1 10h6M8 10h2M11 10h2M14 10h2M17 10h3M21 10h3M25 10h2M28 10h6M1 11h6M8 11h2M11 11h2M14 11h2M17 11h2M20 11h4M25 11h2M28 11h6M1 12h6M10 12h4M16 12h3M22 12h3M27 12h7M1 13h33M1 14h33M1 15h33M2 16h31" />
<path stroke="#ffe3e3" d="M7 5h1M7 6h1M7 7h1M7 8h3M14 8h2M19 8h3M25 8h2M7 9h1M10 9h1M13 9h1M16 9h1M21 9h1M24 9h1M27 9h1M7 10h1M10 10h1M13 10h1M16 10h1M20 10h1M24 10h1M27 10h1M7 11h1M10 11h1M13 11h1M16 11h1M19 11h1M24 11h1M27 11h1M7 12h3M14 12h2M19 12h3M25 12h2" />
</svg>

You can test it out and look at the source on Codepen.

[meyerweb]

Fascinating, shshaw. Thanks for the insights! This is definitely an approach worth investigating.

[shshaw]

Glad that might help!

I've been tooling with the concept more over the past few days and the path + stroke is working as expected in every test case I've thrown at it. Definitely the shortest syntax I could find, and shouldn't be hard to adapt your current setup to that. The main difference would be organizing all the line coordinates and lengths by color then outputting a path for each color.