# Why is SVG not supported by the TeX backend?

I've always wondered why SVG is such a problem for many document creation tools. For example MS Office can't do it, Libre Office can only use very simple SVGs afaik and even in Latex we can't use them properly, but they have to be converted, either manually and then be used as bitmap graphics or automatically by external tools like InkScape. While I like InkScape, this is not satisfying.

Especially from Latex or TeX I'd have expected SVG support, since so many people in the academic world use it directly or indirectly and with so much attention to the detail, that it seems strange to have to go such a workaround way of including SVG in a work. It would be so nice to have a PDF with unlimited zoom and still sharp distinct lines in a diagram for example, instead of some pixelated line, because the SVG was converted before used in the PDF.

So how come we still don't have SVG support in the TeX backend? Would it be so very hard to implement?

I don't know much about the TeX backend, basically only that it exists and converts your stuff into a PDF file, so this question might be naive. On the other hand, you have SVG support in every browser and almost every image viewer software out there, so I think it should be possible to have that. Maybe it's about the PDF format itself not supporting inclusion of SVGs, so that it doesn't make sense to change the TeX backend to allow SVGs, until the PDF format changed?

• Your question is nicely contained in the subject title, so isn't this an unnecessarily wordy expansion of that question (which more or less just repeats that question)? – Sverre Feb 20 '16 at 17:06
• @percusse "scalable vector graphics" is not vector graphics? – David Carlisle Feb 20 '16 at 17:22
• you should be able to convert svg to pdf without making it into a bitmap, it uses essentially the same rendering model as postscript and pdf. – David Carlisle Feb 20 '16 at 17:24
• @DavidCarlisle wrong wording is not equal to is missing – percusse Feb 20 '16 at 17:35
• @Zelphir why would you need a bitmap, just convert to pdf if using pdflatex, see for example svg package tug.ctan.org/graphics/svg/svg.pdf – David Carlisle Feb 20 '16 at 19:07

Classically TeX does not deal with any graphics formats, the dvi file file just contains a pointer to a graphics file to be included by the dvi driver. TeX just needs to know the space to leave, which it can read from a BoundingBox comment or from optional arguments in `\includegraphics`.

It is (usually) much easier to include a graphics format if it is the format that you are generating for the document, as the dvi driver doesn't need to "understand them", just copy into the stream, so for example `dvips` can include EPS files as they are just copied literally to the output, similarly jpg files, and certain bitmap formats that can more or less trivially be converted to PostScript bitmaps.

The situation with pdftex is similar except that it can not handle EPS files but can handle PDF files again because it is much easier to handle PDf if you are writing PDF.

To handle EPS in pdftex you need an external EPS to PDF translation program, which may be called by shell-escape from TeX, but is conceptually (and in fact) quite separate.

The situation with SVG is just the same. If you are producing svg (eg dvisvgm dvi driver) it is easier to include SVG than EPS or PDF, if on the other hand you are producing PostScript or PDF then you need a conversion program, usually incscape, in the loop. Again this may be hidden behind a shell-escape and called from TeX if needed. You should however convert the SVG to a scalable format (PDF or EPS) not to a bitmap, if the final aim is to include into PDF document.

• There are more parts to the puzzle than I knew. So if the DVI driver supported SVG, there would be no problem with SVG in PDF without converting them at all? – Zelphir Feb 20 '16 at 18:22
• @Zelphir "no problem with SVG in PDF" doesn't sound quite accurate. If you are using dvisvgm, for example; then your output is SVG. Obviously, (as @David Carlisle explained here) you can include content in your output format trivially. If your outputting SVG, with the final aim of producing a PDF, then you are simply moving the conversion step to be later in the process (i.e. producing a full SVG document, then using some external tool to convert it to a PDF). – Tersosauros Feb 20 '16 at 18:49
• @Tersosauros So a PDF cannot contain an SVG natively and that's why it needs to be converted, so there is no way around that, even if there was SVG support in the DVI driver? – Zelphir Feb 20 '16 at 18:57
• @Zelphir a dvi driver supporting svg means that either it writes svg (like dvisvgm) or it includes a convertor from svg to whatever the format being written is (pdf or postscript typically) – David Carlisle Feb 20 '16 at 19:04

Put yourself in the shoes of someone who is writing a TeX compiler. There are plenty of programs to convert images to one format or the other (inkscape, imagemagick's `convert`, ...); so why should you spend time on supporting more than one format, which would essentially be the same work as reimplementing a converter from scratch?

In particular, the SVG format contains everything but the kitchen sink: from bidirectional Chinese text on a curved Bézier path rendered in a custom font using a background color pattern, to a full-blown Javascript interpreter. Oh, the horror. No, thanks; your time is better spent fixing bugs and improving the core functionalities.

(Ok, most converters do not support the full functionality set of SVG, agreed, but the concept stands.)

So, in practice you just support one format (or maybe one bitmap and one vector format), and tell your users to use one of the many available external tools to convert graphics into it. Luckily, most of them are smart UNIX users, so they know their way around a Makefile or a build script.

If you want to be an excellent guy, you can support automatic conversion from `eps` to `pdf`, but even that is not your responsibility. Or maybe you could have a chat with the `latexmk` maintainer and ask them to introduce custom dependencies, so this can be automated from their side.

TL;DR: programmers do not like to reinvent the wheel.

• I can see what you're getting at, with all the stuff that's in the SVG format. I didn't know about the JavaScript thing until a few days ago (and I don't see a reason for it being there.) If I was a really motivated TeX developer and had enough time for this, I'd want my tool to be standing on its own legs, but that's me I guess. I wouldn't want to have to rely on other tools. We are talking InkScape and others so it's not as bad, but I'd still feel like my tool is missing something, so it needs help. – Zelphir Feb 21 '16 at 12:15
• @Zelphir really, you wouldn't:-) if pdflatex included every format conversion that has been requested over the years the development (and size of the binary) would be overwhelming. You are interested in svg today (strange choice, actually) but pdftex has had requests for tiff, giff, eps, wmf, ... why should it include convertors for all these things? especially svg would be low priority as I don't know any software that makes svg that can't save the image as some other format. – David Carlisle Feb 23 '16 at 20:55
• @DavidCarlisle Maybe you're right. I've tried to include a PDF, which was exported by yEd and it looks just as good as the SVG file, so I guess no quality loss there. Quality loss was / is my main concern. – Zelphir Feb 24 '16 at 15:02

Creating SVG graphics is supported via the `dvisvgm` package in the TeXLive distribution. It works by converting DVI files (produced by `tex` and `latex` rather than `pdftex` and `pdflatex`).