3 ms·

I just redrew his SVG in Illustrator. 593 bytes. Then I ran it through ImageOptim, which is a frontend to a bunch of jpg/png optimizers and svgcleaner, and got

I just redrew his SVG in Illustrator. 593 bytes. Then I ran it through ImageOptim, which is a frontend to a bunch of jpg/png optimizers and svgcleaner, and got back a 279-byte svg. His is 306. Mine includes the XML namespace his drops, and writes out the path definitions in a very different, more succinct format. It helps that I know to uncheck "save with Illustrator compatibility" so it doesn't cram a whole text-encoded .AI file into the back of the SVG; I also drew one 5-pt polygon instead of a pair of 3-pt triangles. Which does not invalidate his core point about "holy crap some machine-made files are stupidly huge". But hand-writing SVG is like trying to hand-write assembly for a modern CPU - collectively, the people who wrote the compiler probably know more clever tricks about optimizing code than you ever will.

jacobolus 7y ago
If all you care about is the appearance, you can also (in Illustrator) convert the strokes to outlines and then merge all the shapes, and then you’ll just get a single filled path.
- egypturnash 7y ago
  Hmm, good call, that gets it down to 122 bytes after optimization. I was mostly optimizing for "minimum time and thought spent vs. reading the SVG spec and hand-writing a file". Oddly enough if I prune out the four seemingly-superfluous points that result where the shapes overlap it goes back up to 125. SVG's path compression is weeeird. 13 points, 122 bytes: <svg viewBox="0 0 54 54" xmlns="http://www.w3.org/2000/svg"><path http://www.w3.org/2000/svg"><path d="m27 23-27-27v4 27 27h4v-27h46v27h4v-27-27-4z"/></svg> 9 points, 125 bytes: <svg viewBox="0 0 54 54" xmlns="http://www.w3.org/2000/svg"><path http://www.w3.org/2000/svg"><path d="m27 23-27-27v58h4v-27h46v27h4c0-12 0-46.1 0-58z"/></svg>
  - jacobolus 7y ago
    You can shorten d="m27 23-27-27v4 27 27h4v-27h46v27h4v-27-27-4z" to d="m27 23-27-27v58h4v-27h46v27h4v-58z" The cubic bezier curve in your second version seems like some kind of strange artifact.
oxguy3 7y ago
I'd be curious to see the source of your SVG -- it may be smaller but I wonder how it'd compare on readability and ease of making modifications to it.
- egypturnash 7y ago
  <svg viewBox="0 0 54 54" xmlns="http://www.w3.org/2000/svg"><path http://www.w3.org/2000/svg"><path d="m2 54v-54" fill="none" stroke="#000" stroke-miterlimit="10" stroke-width="4"/><path d="m52 54v-54" fill="none" stroke="#000" stroke-miterlimit="10" stroke-width="4"/><path d="m0 27h54v-31l-27 27-27-27z"/></svg> Far inferior in human-friendliness to read and edit. But less bytes, and editing would realistically involve loading up the AI source file I didn't bother saving and generating a new SVG.
m463 7y ago
I tried making a few SVGs a while back by hand. I loaded them into inkscape and... ugh. Numbers like 10 30 became 10.0000023 29.9999948 and basically everything became complicated. It was like running a one-line program through a compiler and then a disassembler.

jacobolus 7y ago

If all you care about is the appearance, you can also (in Illustrator) convert the strokes to outlines and then merge all the shapes, and then you’ll just get a single filled path.

egypturnash 7y ago
Hmm, good call, that gets it down to 122 bytes after optimization. I was mostly optimizing for "minimum time and thought spent vs. reading the SVG spec and hand-writing a file". Oddly enough if I prune out the four seemingly-superfluous points that result where the shapes overlap it goes back up to 125. SVG's path compression is weeeird. 13 points, 122 bytes: <svg viewBox="0 0 54 54" xmlns="http://www.w3.org/2000/svg"><path http://www.w3.org/2000/svg"><path d="m27 23-27-27v4 27 27h4v-27h46v27h4v-27-27-4z"/></svg> 9 points, 125 bytes: <svg viewBox="0 0 54 54" xmlns="http://www.w3.org/2000/svg"><path http://www.w3.org/2000/svg"><path d="m27 23-27-27v58h4v-27h46v27h4c0-12 0-46.1 0-58z"/></svg>
- jacobolus 7y ago
  You can shorten d="m27 23-27-27v4 27 27h4v-27h46v27h4v-27-27-4z" to d="m27 23-27-27v58h4v-27h46v27h4v-58z" The cubic bezier curve in your second version seems like some kind of strange artifact.

oxguy3 7y ago

I'd be curious to see the source of your SVG -- it may be smaller but I wonder how it'd compare on readability and ease of making modifications to it.

egypturnash 7y ago
<svg viewBox="0 0 54 54" xmlns="http://www.w3.org/2000/svg"><path http://www.w3.org/2000/svg"><path d="m2 54v-54" fill="none" stroke="#000" stroke-miterlimit="10" stroke-width="4"/><path d="m52 54v-54" fill="none" stroke="#000" stroke-miterlimit="10" stroke-width="4"/><path d="m0 27h54v-31l-27 27-27-27z"/></svg> Far inferior in human-friendliness to read and edit. But less bytes, and editing would realistically involve loading up the AI source file I didn't bother saving and generating a new SVG.

m463 7y ago

I tried making a few SVGs a while back by hand. I loaded them into inkscape and... ugh. Numbers like 10 30 became 10.0000023 29.9999948 and basically everything became complicated. It was like running a one-line program through a compiler and then a disassembler.