svgelements does not process Symbol

[tatarize]

https://www.w3.org/TR/SVG/struct.html#SymbolElement

The ‘symbol’ element is used to define graphical templates which can be instantiated by a ‘use’ element but which are not rendered directly.

A ‘symbol’ establishes a nested coordinate system for the graphics it contains. When a symbol is instantiated as the referenced element of a ‘use’ element, it is therefore rendered very similarly to a nested ‘svg’ element.

[ptomulik]

Note, that currently svgelements produce elements for <symbol> contents itself as well as for any occurrence of <use> that refers that <symbol>. Looks like a bug.

[tatarize]

Yeah, I needed to look more into symbol. I didn't really have a use for it enough to flesh it out with more fully processed objects and I don't think I understood the distinction enough to write a Symbol class. But, I could certainly see the combination of <use> being treated more correctly actually leading to this defect becoming more of an issue. You do get the raw node and whatever sorts of things it should inherent but here it could have some weird effects that I didn't understand/realize that maybe go beyond read it out of the generic SVGElement class and figure it out yourself.

--

There's also some issues with #87. I've somewhat been treating this project as bug and maintenance mode for a year or more now, and correcting issues like failure to process a particular element type when they came up. Part of my reasoning is that I understand the methodologies here have a rather fundamental flaw, in that, the failure to treat the DOM tree and Render Trees and fundamentally different things, causes a lot of needless complexities, and makes some features impossible when they should be fairly trivial. EG. CSS applies to nodes in the DOM tree and those modifications can be a lot of different stuff it affects the render tree only after render. In our case, render could give us a much more fundamental set of geometric objects with the right properties rather than quasi-hybrid Rect objects, for example. But, currently if CSS is given towards the end of parsing it can't apply to already rendered objects. Also, somethings like visibility: None gets no nodes produced because parse is intended to give you the render tree, which does not give you those objects (per the spec) or degenerate shapes.

About 13 months ago I wrote the start of a different svg project to try to rectify this but I haven't really had time to work on it and the code is still sitting in a private repository. It can load a SVG file, modify the DOM, and save the 1:1 read->write data, letting you modify SVG files, but it doesn't currently do the rendering of that tree state into geometric objects, which is the second part (both parts are done by svgelements as a single parse stage). But, knowing this project has this flaw, and that this project is really nice work, I've been reluctant to flesh out too many other classes that I haven't needed or yet fully understand. I have tried to make sure everything follows the spec nicely, and that bCNC, MeerK40t, vpype and any other program that uses this library for the promise of correctly parsing the svg spec into geometric objects gets high fidelity results.