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 :)
No luck
> SVGO
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 :)