You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When parsing an SVG that uses CSS styling, the styling is applied correctly, but the styling information (<style> tag defining style for certain tags and classes) is lost. This means when writing the SVG any style information is applied directly to each element. This reduces the readability of the SVG and makes easy manual edits (e.g. changing the color of elements with a certain class or type) harder.
Proposed Solution
The <style> tag becomes a parseable element that is part of an SVG object. I think it would be fine if only stroke, fill and stroke-width are the only supported attributes for now. If there are multiple style tags, I suppose they should be merged.
The class of an element (if present) is added to the parsed object
A parsed GraphicObject stores a reference to the Style object of its SVG object (if any).
The attributes of GraphicObject become properties. These return the stroke/fill/stroke-width fields as defined by the Style element or the attributes directly set on the element, respecting the precedence of the SVG spec.
When writing the SVG to disk, the Style tag is added to the output.
The text was updated successfully, but these errors were encountered:
robinwersich
changed the title
Class attribute / styling information is not stored when parsed / cannot be written
Class attribute/styling information is not stored when parsed / cannot be written
May 15, 2023
The actual solution to this would be to properly implement svgio.
The core of the idea is that all nodes are parsed as nodes. When you need the geometric objects you can request a render. And you get a rendered set of geometric objects. That's it. If you want to modify the original nodes you may do that, and it's fine. But, it won't change anything but the nodes and node-states. Then when you save out, you get the original state of all the nodes. You can also modify nodes and create nodes.
The trick is render() gives you the actual geometric objects, so it doesn't need to be a state-node hybrid thing. You can change a color on some node, whether it trickles down to the other nodes or is a that appears in some objects etc. Doesn't matter. The rendered data is a series of colored and filled paths. These may point back to the node that created it, but you get full distinction between the DOM and the rendered geometry.
When parsing an SVG that uses CSS styling, the styling is applied correctly, but the styling information (
<style>
tag defining style for certain tags and classes) is lost. This means when writing the SVG any style information is applied directly to each element. This reduces the readability of the SVG and makes easy manual edits (e.g. changing the color of elements with a certain class or type) harder.Proposed Solution
<style>
tag becomes a parseable element that is part of anSVG
object. I think it would be fine if onlystroke
,fill
andstroke-width
are the only supported attributes for now. If there are multiplestyle
tags, I suppose they should be merged.GraphicObject
stores a reference to theStyle
object of itsSVG
object (if any).GraphicObject
become properties. These return the stroke/fill/stroke-width fields as defined by theStyle
element or the attributes directly set on the element, respecting the precedence of the SVG spec.Style
tag is added to the output.The text was updated successfully, but these errors were encountered: