Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Class attribute/styling information is not stored when parsed / cannot be written #234

Open
robinwersich opened this issue May 15, 2023 · 1 comment

Comments

@robinwersich
Copy link

robinwersich commented May 15, 2023

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.
@robinwersich 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
@tatarize
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants