Author here. I am also using Firefox (on Linux) and the image is displayed fine. I don't know exactly what you mean by jumbled, but I don't hard-code fonts in the SVG: it uses the default sans-serif font of your system. May this explain what you get? I am usually careful with the anchor points and leave some additional space to ensure it is displayed correctly with whatever font is used.
A solution would be to convert the text to paths, but I didn't find any tool that would do that efficiently. With Inkscape, there is a serious size bump when doing that.
> With Inkscape, there is a serious size bump when doing that.
Yes, you can't really avoid that when converting text to path objects, there is no way to do something similar to PDF's subset embedding AFAIK.
I've tried to get SVG diagrams with text to work, but they just always fall apart somewhere. High-resolution PNG or inflated SVG seem the only viable methods. svgz (svg+gz) helps with the size inflation, but is not supported by Firefox when accessing local files.
It's kinda a shame that web browsers can't display single-page PDF documents in-line, as images.
SVG can be served gzipped transparently. Ideally, when converting text to path, each letter (or group of letters) should be put in a group which can be referred with <use>.
Thanks for the example. Is the text in other figures OK?
No, they're all affected like that which is also my general observation. I'm not sure what causes it (possibly differing default font sizes, zooms or font selection). Chrome seems to generally use less defaults from the platform than Firefox, as is the case here as well — Chrome renders the figures fine. It usually does, though it can't help with missing fonts.
> Ideally, when converting text to path, each letter (or group of letters) should be put in a group which can be referred with <use>.
Oho, that's a very interesting idea! Might be possible as a post-processing step, depending on how exactly Inkscape converts runs of glyphs (I never looked inside one of those 1.5 MB SVGs...).
> SVG can be served gzipped transparently.
Yes; in my case the figures are mostly in docs, so checked-in size matters; colleagues have to pull changes and pushing xx MB for figures (and frequently updating them as well — something that git does not handle well) is not nice. For open source, it ends up in the source distribution. I think in one of my projects it was inflated by xxx % due to that :D
Some hard numbers: A not-that-complex figure showing a workflow. The .vsd is 145 kB, the PNG is—after optipng—about 1 MB and the SVG was iirc around 2.5 MB (Visio->SVG->Inkscape on the same machine otherwise results are bad->Convert To Paths->SVG), not gzipped since that kinda breaks local editing (with Firefox). While the high-resolution PNG looks good in print, scaling it to displays ain't that great and text doesn't look sharp. SVG needs a separate conversion for print (SVG[->PS]->PDF).
> Oho, that's a very interesting idea! Might be possible as a post-processing step, depending on how exactly Inkscape converts runs of glyphs (I never looked inside one of those 1.5 MB SVGs...).
I would hope that something like svgo could do that. BTW, due to an error on my side, the SVG images didn't get processed by SVGO. I just fixed that, maybe this would help.
Interesting tool, didn't know about it. It certainly works and reduces the size of a SVG with path-based text by ~50 %. Further, gzip'ability is increased as well. I tested this with a 1.4 MB SVG, SVGO shrunk it to 765 kB, and gzip compresses it further to 100 kB. The original SVG is only compressed to about 260 kB, thus gzip compression is enhanced by ~20 % by SVGO.
On the other hand, neither Gwenview nor Karbon display the SVGO'd figure as it was. Firefox and Chrome seem to render it fine. rsvg-convert results in a large and slow PDF.
At this point the "technically best" option to me seems to be
(1) create an SVG, convert text to paths on the same machine, use SVGO and gzip (and just use python -m http.server or sphinx-livehtml or similar for local editing) for HTML and
(2) create a PDF completely separate from the SVG processing chain for print, since no SVG to PDF conversion is satisfactory (file size, preservation of contents, rendering / printing time—stuff that is slowly rendered is slow to print as well!).
... and then tell the rest of the content pipeline that figures are now in two formats. Ugh.
Anyway, my illustration troubles are a bit off-topic to your great article :)
