SVG extract should wrap in an outer group

[jrflood]

This is in fact already the case. The group has the id of "xlt" and contains the transform, which is reset to translate(0,0) scale(1) yielding image-pixel-referenced coordinates. This group is contained by the <svg> element.

[mjy]

When we export the SVG we will want no id attribute I believe.

[jrflood]

This group is crowbarred to a no-translation, no-scale default, which means it has no real effect except encapsulation. It is fairly simple to eliminate the transform and scale attributes, as well as the ID. Do you want the containing <svg> element similarly de-identified? There are currently three API-ish entry points for SVG extraction, verbatim, "plain", and JSON, where the last two are depopulated.

[mjy]

Can you update the README.md example to illustrate the current state?

Now I'm thinking we're going to need encapsulation after the persistence of this object somewhere else (e.g. TW), so this issues is likely in error on my part.

[jrflood]

There has been a presumption that SVG annotations would be styled by CSS. Unless there is a concern over storage, there may be value in leaving stroke, fill, etc. attributes as created, such as visualization of source information or subsequent editing.

Until now, each graphical SVG element or composite/alias element has been contained in a group with a class attribute. While the svg-detailer is intrinsically a multi-element editor, you have leaned toward a single graphic item. In order to distinguish items that have been created by different people or at different times, you could add an attribute (e.g., subclass or id) to the element to style it with CSS (or just add a fill attribute inline). It may be not drastically different whether the CSS is styling groups or both groups and lower level elements.

[mjy]

Re persitence - I prefer to exclude non structural assertions in the one mode of export.

Re editing- see #19. I don't see this as a tool to persist and edit SVG, only produce SVG to be later "read only". Even if styling elements are required for editing, then we should persist them at the outer layers (groups) so that we can render them back from the persistence layer, rather than the individual elements, right?

I.e. we can persist "naked" SVG, and render it back with the required stroke- etc. if those are required by svg-detailer. Why go to this steps? The percieved back-end will handle SVG produced anywhere, not just svg-detailer. Therefor we're going to need to be able to render, in that tool, the elements necessary for "editing" in svg-detailer anyways, if such things exist.

[jrflood]

I resisted the term "naked" even though it was about the first thing that came to mind. The extraction method now exists (SVGDraw.prototype.apiBareSVG), such that the noGroups argument being true eliminates all groups where the class and the element tag are the same.

[jrflood]

My admittedly limited testing suggests that while CSS can override inline style attributes in elements, this doesn't translate into inheritance of style from containing groups. The only downside I see to maintaining (or not removing) inline attributes is the number of bytes necessary to represent them.

The synthesis of elements, attributes and listeners necessary for editing in svg-detailer is addressed briefly in #19. There are nuances related to grouping that make the issue of importing "interesting". An "externally" created SVG could group several elements as a logical element, and editing the lower level elements separately might become awkward.

In svg-detailer, there is only limited recursion currently, such that "super-groups", or complex/compound elements are only supported for things like "arrow". There is no fundamental reason why the user interface couldn't be extended to allow user-defined grouping.