Understand better the constraints around text labels and layout about visualisation-tool HOT 4 CLOSED

I went to a talk ages about by Terence Eden from NHSX where he was talking about the various possibilities around JS in SVGs. This particular use case was at the back of my mind and it felt like it should be possible to wire up one of two options:

• Preprocess labels to generate some key stats about them (eg lines, line breaks, width) and then supply that as an API that the client side can call to make decisions about rendering
• Try to come up with some rules about rendering, and make the client evaluate them in order to work out the final layout

Neither really felt good, but the fact that the JS to do them could be embedded in the SVG felt like some really nice containerisation, especially as you have the option to dynamically generate that JS on the server side.

Of course, that might also be WAY too complex for what we're doing here, and may well not play nice with existing tech, but I saw this fly past and I figured I'd stick my oar in!

from visualisation-tool.

Thanks @robredpath - that's very interesting! I wonder how well drawing tools like draw.io or inkscape deal with embedded JS.

Either way, I think we're planning to try moving away from SVG first (#8), but it's good to know we might have other options.

from visualisation-tool.

This issue is resolved if we use labels exclusively for visualising the node (i.e. the icon and the text are part of the label). The node itself can become a transparent container for the label that will resize dynamically when rendered and control the intersection point for the edge. We can control this intersection point if necessary but I've found the built in shapes and intersection points to be pretty robust.

The decision then is between SVG labels and HTML labels.
HTML provides much better handling of text (positioning, centering, wrapping, etc).
SVG maintains the convention and allows downloads etc.

As discussed in #8 we might be able to leverage the benefits of both depending on the use case, or utilise HTML alone for greater text control.

from visualisation-tool.

I'm pretty happy to close this and just say that using HTML solves our problems. In the interest of directness, I'll do that now and let anyone who disagrees re-open it :)

from visualisation-tool.