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
Check this if you would like to implement a PR, we are more than happy to help you go through the process.
What problem are you trying to solve?
The SVG generated by Chartist does not work outside of browsers. Image viewers cannot handle foreignObject and the erroneous xmlns property used inside. Also, because CSS is used for a lot of the styling, an exported chart is completely transparent.
Describe the solution you'd like
A chart export function that iterates the SVG tree and generates a new SVG, using getComputedStyle to add stroke colors, widths and other styling to the chart elements.
Describe alternatives you've considered
I don't see much alternatives except rendering a PDF or similar, which is very brittle.
Documentation, Adoption, Migration Strategy
My current approach is a separate function that traverses the SVG object to create a whole new SVG. It works for my current use case, but might not be elaborate enough for all use cases.
The text was updated successfully, but these errors were encountered:
Hi there. The plans in the pipeline are that we create a complete "virtual SVG dom" within chartist before rendering and that rendering is the last step in the pipeline. Unfortunately, I did not have much time to work on this rewrite recently. I have made an earlier attempt, and I think I can pick that up again soon. This will most likely just mean that we need to rewrite Svg to store internally a virtual DOM and then just render in the end. We can also use different renderers (DOM, SVG image etc). This will also have a large impact on Plugins and probably existing code when they have relied on DOM directly being created and manipulated. My idea was to use new event names for all Chartist events when switching to the new architecture, exposing only virtual DOM and asking users to use the Virtual DOM for modifications during events etc. Then we could publish a new plugin "Legacy Events Plugin", which is creating real DOM in every virtual dom event and emitting the old events using the created DOM. Something like this, I need to think about it again. It's 4 years ago :-D
I'm telling you this because this has a large impact on your possible contribution. If you want to help with this effort, I'd be more than happy to do this in collaboration.
Would you like to work on this feature?
What problem are you trying to solve?
The SVG generated by Chartist does not work outside of browsers. Image viewers cannot handle
foreignObject
and the erroneous xmlns property used inside. Also, because CSS is used for a lot of the styling, an exported chart is completely transparent.Describe the solution you'd like
A chart export function that iterates the SVG tree and generates a new SVG, using
getComputedStyle
to add stroke colors, widths and other styling to the chart elements.Describe alternatives you've considered
I don't see much alternatives except rendering a PDF or similar, which is very brittle.
Documentation, Adoption, Migration Strategy
My current approach is a separate function that traverses the SVG object to create a whole new SVG. It works for my current use case, but might not be elaborate enough for all use cases.
The text was updated successfully, but these errors were encountered: