Remove some inkscape-isms from the SVGS

[Ericson2314]

Done by hand using http://jsfiddle.net/alexanderby/31nmr8f7 as advertised in
https://graphicdesign.stackexchange.com/questions/49626/what-program-makes-clean-plain-svg-files-from-inkscape

I haven't done much with SVGs in years, but I recall that most of this stuff is just noise like remembering editor views etc that don't really constitute source. We should regenerate raster images to to confirm no useful information is lost.

[samueldr]

Side thumb on this (down and up) right now.

It depends on what exact metadata this removes. I know that inkscape saves some things that SVG cannot represent, which can then be re-used by inkscape as required. From memory, those are things like layers, grid or guides. I'll have to look more in details what this touches.

And I think it also depends on what's the goal. If the goal is to reduce the size of the SVG for use wholesale on the web, it would be better to save as plain SVG, and furthermore use SVG optimizer tools. They do more than simply removing cruft from the editor. The "source" of an inkscape SVG file is more than just the SVG it represents.

What I usually do when I have to manage SVG source and SVG documents for use is to have file.src.svg be the complete inkscape document, and then save file.svg for use without cruft, and finally preferring to save the optimization step into an assets pipeline if applicable (as the optimizers are often lossy).

[samueldr]

Note about the second commit coming in later.

The duplication removed is the "flat" snowflake (without gradients), for printing. The previous commit with metadata removal did in fact remove the layer metadata from inkscape.

This is now a thumbs-down as it removes important metadata from the source document, for editing.

---

EDIT: Sorry if the terseness seems abrupt and borderline rude! I should have prefaced with thanks for taking interest and contributing to the artwork repo!

[Ericson2314]

Yeah I feel you. It irks me that inkscape doesn't really seem to disambiguate between the various things SVG can't represent: I suppose the real questions are "does the extra information somehow affect the SVG that does exist?" and "to what existent is the pure SVG elements src or a build artifact?". On one hand, scrapping source for generated data and committing that is awful. On the other hand commiting the equivalent of "what font I use in sublime" or whatever is superfluous.

Feel free to ignore this for a bit. I'm going to keep on trying to cut down the size of the snowflake without loosing information or structure (injective but not surjective generation of data would be lossless in some sense but still bad) and see what I end up with.

[samueldr]

Some of the metadata (like the current position in the viewport) I agree are not to be there; but there are some that are important when authoring, like the layers metadata.

If we want to make parallels, the viewport information (current zoom, showing grid) are like saving where in the file sublime is scrolled to. The grid configuration, guides and layers metadata here are more akin to comments into the source code; they aren't used in the final compiled artifact, but are of value.

[Ericson2314]

I can be on board with that. In the snowflake case, are the layers any good? I don't know enough, but duplicating everything for a flat print layer seems bad unless tools besides Inkscape know how to keep them in sync. I also want to make a two-deep <use> so we don't need to repeat path information for each lambda.

Also ugh inkscape showed the image fine in that last commit while I made it, but barfed when reopening it.