Scalable Vector Graphics Support

SVGs (Scalable Vector Graphics) have the general benefit of being independent of the resolution of your client and have a description language which looks a lot like CSS/HTML with different tags. As they do not contain the actual pixel information but drawing information on a canvas, they are much smaller and can be resized as needed - because your rendering software (e.g. the software you open the SVG with) translates the SVG text into actual pixels.

The way that works can be imagined like the turtle draw which is a common approach to teach visualization on a canvas.

Is SVG generally better?

While I generally try to use SVG as a source format for most visualizations, this does not always work out perfectly, though this also maintains the easy possibility of changing the graphic with a program like Inkscape.

Though there are two caveats to that, which are the size and the compatibility, described in the following.

Size

It is generally preferred to use SVGs when having simple graphics without too many edges, as the file size is much smaller because only the line information is contained and not all pixels - rendering the graphic with a basically infinite resolution.

On the other hand, when having many small lines in your graphic, it can on one hand take longer to render the picture, while such SVGs can also be a lot larger than lossy compressed formats like PNG and JPG.

In the Freifunk context, there are a few examples of 3d figures where this is the case. Router device pictures for the download section of a freifunk community (see here) also have this, like this one:

Which is bigger than the 256x256 jpg version of the same picture.

Compatibility

When writing \(\LaTeX\) one has the problem, that SVGs are not valid includegraphics extensions by default. One option to solve this is the SVG package from CTAN which requires Inkscape under the hood, which is a pretty big dependency and not available in some \(\LaTeX\) CI images. So you first need to convert your SVG to PDF before using it. This on the other hand has the nice benefit of making the text in the PDF clickable, searchable and markable - though it requires some extra work.

But there are much greater compatibility issues.

The LibreOffice suite has problems with rotated text, as rotated text on an axis is not correctly rotated on the final SVG.

Microsoft Office has problems exporting to SVG and adds or misses a space in a simple headline and is not a much better fit for this. In that case I worked around that by using Inkscape to edit the file afterward, though this is still not very easy.

Draw.io (aka diagrams.net) embeds a “This viewer is not compatible with SVG 1.1 standard” to all exported images, which is shown on old viewers. The default Gnome viewer still shows this watermark, making it impossible to use “Formatted Text” if compatibility with the old standard is required.

The actual rendering might be different depending on your client which can be bad, just as it is the case for PDFs. For example, if the watermark would show something different depending on the client, this can be a real security issue, if SVGs are embedded in some important places, like contracts. This is surely no problem singular to SVGs, but also to HTML/CSS and PDF which are majorly used.

Final say

Even though there are many compatibility issues, I stick to use SVGs primarily, and just hope, that I will look back to this post in a few years and see that every client adopts the SVG standard from 2018 correctly.