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 :)
> 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).