Truly Headless Draw.io Exports
I was puzzling over Eye of GNOME’s misrendering and wondering what the SVG could possibly be to render so, right up until the point you mentioned the use of foreignObject. Ah, HTML in SVG, got it. Seems a strange choice for export, rather than resolving the layout into text&#x2F;tspan elements. The only <i>reason</i> that I can think of (other than ease of implementation&#x2F;laziness) for doing things with foreignObject is so that it can reflow into the available space if a different font gets used, since you can’t depend on the specified font being used; yet I expect such reflow would break at least as many cases as it improved, since the containers for the text are a fixed size. There is no universally correct option for such font substitution in a fixed-dimensions format like SVG mostly is, so I would have thought you’d stick with pure SVG since foreignObject HTML loses you so much compatibility. Calling it SVG export when SVG editors as a class can’t handle it is extremely surprising and I think rather tacky. (See also <a href="https:&#x2F;&#x2F;desk.draw.io&#x2F;support&#x2F;solutions&#x2F;articles&#x2F;16000042487-why-does-the-text-of-svg-export-sometimes-not-display-correctly-in-ie-and-some-svg-editors-" rel="nofollow">https:&#x2F;&#x2F;desk.draw.io&#x2F;support&#x2F;solutions&#x2F;articles&#x2F;16000042487-...</a>, sounds like you can disable word wrap on each text box and that’d stop using foreignObject.)<p>A more interesting option in this format balance would be doing the entire layout in HTML, and only using SVG for drawing boxes and lines and such when CSS is insufficient. This would certainly be a whole lot more work, requiring deeper layout semantics on the diagram, but could allow better responsive design on the diagram as a whole.