Inkscape - Saving Bandwidth with Inlined Attributes

Sun, 10/07/2007 - 05:52 — jh

This is a simple lossless tweak, which can save a few bytes here and there. Close Inkscape if it's running then open preferences.xml (C:\documents and settings\<you>\application data\Inkscape or ~/.inkscape/) with a text editor and search for "inlineattrs".

You should see something like:

<group
   id="svgoutput"
   usenamedcolors="0"
   numericprecision="8"
   minimumexponent="-8"
   inlineattrs="0"
   indent="2" />

Change the value of inlineattrs to 1. Feel free to change other values, if you know what you're doing. (Make a backup if you don't.)

Now you get slightly more compact markup.

Before:

<g
   inkscape:label="Layer 1"
   inkscape:groupmode="layer"
   id="layer1">
  <path
     style="[...]"
     d="[...]"
     id="rect2204"
     sodipodi:nodetypes="ccccc" />
</g>

After:

<g inkscape:label="Layer 1" inkscape:groupmode="layer" id="layer1">
  <path style="[...]" d="[...]" id="rect2204" sodipodi:nodetypes="ccccc" />
</g>

If you occasionally edit your SVGs by hand, you may want to refrain from doing this change. Well, personally I prefer it this way. Oh yea, I claimed it saves some bytes. Let's back it up with some numbers:

File	Default	Inlined	Saved
4 Nodes single shape (Inkscape SVG)	2,158	1,949	9.7%
4 Nodes single shape (compressed Inkscape SVG)	970	944	2.7%
Complex drawing (Inkscape SVG)	1,337,045	1,197,990	10.4%
Complex drawing (compressed Inkscape SVG)	188,760	185,273	1.8%

It doesn't really save that much (compared to gzip compression), but I think it's totally worth it, given that it so easy to do and has virtually no drawbacks.

jh's blog

Comments

Mon, 10/08/2007 - 07:44 — Anonymous

The unix way

Perhaps a separate tool would be better for doing this kind of lossless xml compressions? You can just throw away the line endings and indentation in any xml file.

Mon, 10/08/2007 - 09:42 — jh

Sure

SVG markup has lots of room for optimizations. The first thing, which comes to mind is the styling. Currently Inkscape's inline styles are overly verbose and also overly repetitive. Gzip compression sorts that out for the most part tho.

Another thing is combining paths (can be manually done with ctrl+k), which allows you to re-use the inline style/class/id. That alone can yield massive savings.

And the easy stuff like stripping unnecessary attributes (eg ids), defs (File->Vaccum Defs), spaces and new lines can obviously also save some bytes (as seen above).

There is even more. You could also reduce the accuracy (less digits), remove stuff which is totally covered by other things or which are outside of the view port or even simplify paths partially. Well, doing that would be amazingly hard. Also identical objects could be replaced with clones etc.

There really is lots of room for optimizations. But as usual you'll hit a point of diminishing returns rather quickly. Most of the really complicated tweaks won't really help that much and are very easy to do for humans anyways.

If I were to write such a tool, I would most likely rebuild the styles, auto-generate classes/ids (shortest possible names), combine paths (same style and "next" to each other) and strip everything I can. Doing all that would be fairly simple and would result in a ~80% optimal result, I would say.

kaioa.com