add example code for multiple svg.js instances

[Neonit]

No description provided.

[Fuzzyma]

Actually this is not the intended way to use this lib. Its more a sideeffect that this is possible.
And I am not entirely sure if it does not lead to bugs. Thats why I cannot merge it atm.

[lwallent]

@Fuzzyma could you perhaps elaborate a little on your above comment? Assuming you are using svg.js on the server side (using node.js) generating multiple svgs. What would be the preferred approach?

[Fuzzyma]

Atm: None. I just didnt want to make the jump to 0.2 yet because it would be a breaking change. You wouldnt import a window but a window class or factory which you can use to create as much windows as you need.
The problem here is, that svg.js always only works in one window env. So its kinda useless for your usecase.

However there is another simple solution as I think about it:
If you want to have more svgs in ONE document, you would simply use one root svg and created a bunch of nested svgs like this:

const canvas = SVG(document.documentElement)
const svg1 = canvas.nested()
const svg2 = canvas.nested()
// and so on

[Fuzzyma]

The problem I see with your approach is, that you basically create a bunch of detached svgs. So there will be problems with methods which search for #document in the parent tree. I think the above solution is the cleanest

[lwallent]

@Fuzzyma, thank you for the reply.
My aim is to create separate detached svgs on a webserver on demand. When reading your comment to the PR made by @Neonit, I was just trying to understand what problems I might be facing? :-)

[Fuzzyma]

@lwallent honestly I am not entirely sure. I guess there are the same problems as with regular detached elements on a website. So #document is not in the parent tree and viewportElement might not be set and ownerDocument and so on. As long as it works, it works :D.

[lwallent]

@Fuzzyma I was asking as I was experiencing some strange issues, when I deployed my svgdom based solution on Azure!?
I have now finally found the root course of the problem: I am using base64 resource URIs inside my SVGs to make them self contained. These are not handled correctly by image-size on which svgdom is depending.
I have made a PR on image-size to add the support:
image-size/image-size#144

From the trenches
The error produced is handled correctly by svgdom on Mac/Linux, but when deployed on Azure inside IISNode the svg-generation just silently explodes!? It turned out when Microsoft looked into the matters that Access violations (the looking up non exising files?) was triggering a restart of my node application??

Oh well, sorry for the detour on this Pull Request :-)

[Fuzzyma]

@lwallent oh wow thats interesting. I hope it wasnt to hard to track it down :D. If you want you can create an issue for the problem which we will close when imagesize was updated. May I ask how you use svgdom? Do you use it together with svg.js?

[lwallent]

@Fuzzyma I will create an issue shortly :-)

Yes I use svgdom together with svg.js and svg.filter.js - great work by the way :-)

As mentioned in the start of this thread I use it in a setup somewhat comparable to the one described in this pull request - potentially serving up enormous amounts of svgs from the same svgdom through a rest based web API.