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

Implement SVG graphics export #1378

Open
1 task done
nkoehring opened this issue Nov 4, 2022 · 1 comment
Open
1 task done

Implement SVG graphics export #1378

nkoehring opened this issue Nov 4, 2022 · 1 comment

Comments

@nkoehring
Copy link

Would you like to work on this feature?

  • 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.

@gionkunz
Copy link
Collaborator

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.

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

No branches or pull requests

2 participants