Commit b6e57db8 authored by Nicolas Lenz's avatar Nicolas Lenz
Browse files

Add article SVG

parent af771595
Pipeline #849 passed with stage
in 8 seconds
title: "SVG: The Good, the Bad and the Ugly"
date: 2021-02-12
tags: [Computer Science, SVG, Web, Language Design, Graphics]
link: res/thumb/svg-logo.png
alt: The SVG logo.
abstract: SVG, short for *"scalable vector graphics"* is a format for, well, scalable vector graphics. In this article I summarize my opinion of the format, what its problems are and suggest what could be done to improve things.
![The SVG logo.[^i]](/res/article/svg-logo.png)
[SVG](, short for *"scalable vector graphics"* is a format for, well, scalable vector graphics. In this article I summarize my opinion of the format, what its problems are and suggest what could be done to improve things.
I've been using SVG together with Inkscape regularly for a few years for sketches and graphics, and like to write it by hand to satisfy my love for precision and art through code. SVG and I have a kind of love-hate relationship. It's powerful and has some nice free and open-source tooling, but the format itself is pretty ugly.
## The Good
- It's *the* format for vector graphics. It is well supported by a range of programs from Adobe Illustrator to Inkscape for editing and in various browsers.
- It's a web standard so you can use it directly in websites. You can also use CSS with it.
- It's XML-based, so the syntax is familiar, it's extensible and can benefit from the vast XML ecosystem. For example, using [XLink]( you can reference other elements and definitions in an SVG file. Or [Inkscape]( uses custom XML tags to extend SVG into their editor exchange format.
- It's powerful. You can do *a lot* with it. It obviously supports various path types and shapes, supports text and more, but also animations, gradients, effects and more.
## The Bad
It's a web standard. And as is customary for a web standard, SVG is magnificiently bloated. The [SVG specification]( brings a whopping 826 (*eight-hundred twenty-six*) pages to the table. And as if that's not enough, it's also XML-based and cross-linked with other web standards, driving the scope of any implementation to dizzying heights.
If you want to be sure to correctly render all SVG files, not only do you have to consider 800 pages of SVG spec, but e.g. another 20 pages of [XLink spec]( Oh, and CSS as well, by the way. And, I shit you not, *JAVASCRIPT*. Yes. [SVG files can include `<script>` tags.](
SVG fits right in with web browsers. There hilariously bloated already, they already implement stuff like CSS and JavaScript that a complete SVG implementation requires. This problem of SVG is actually just the [problem of the web in general]( It's scope is huge, it's bloated and hard to work with.
SVG is nothing you could implement in a day. Or a week. Or a month. The huge amount of specifications, that are most often only partly implemented, makes it very hard to overview what supports what, confusing the user as to what features they can actually use if they want their SVG file to be universally supported.
Furthermore the XML-based syntax is pretty ugly and needlessly verbose. It's tiring to write by hand and just as tiring to parse or generate automatically.
## The Ugly
A central problem that can be extracted from the points listed above is the one I detailed in my article about [language design for machines vs. humans](/article/language-design-machine-or-human.html): SVG doesn't know what it wants to be, a machine-focused language or a human-focused language and ends up doing badly in both aspects.
Is it a machine-processible language? It's far too bloated for that. Writing parsers, renderers and generators for SVGs is a huge task. The syntax is repetitive and complex. It has a lot of features that could be represented by more basic features.
But is it a format well-suited for direct usage by humans? Well, no. Firstly, the exhausting syntax and complexity is also bad for human users. Secondly, it misses a lot of features that would make it suitable for direct use. A graphics language that is meant for direct human use would be [Ti*k*Z]( for LaTeX. While it's not a great language regarding user experience in my opinion, it is definitely meant for humans and has the necessary features to help making creating complex graphics easy. But nobody would have the idea to use Ti*k*Z code as an interchange format for the finished graphic. Nobody would want to implement 1300 pages of Ti*k*Z manual just to view some graphic. Instead you compile it into an PDF (which is also a horrible format and badly bloated, but well). If SVG was a language meant for human use, compiling it into a machine-focused format would be the way to go as well, but as I said – it isn't. It's neither.
## What now?
A good idea would be to develop a simple vector graphics exchange format that is desigend to be easily processed by machines. As minimal in features as possible. Maybe JSON-based, definitely not XML-based. You should be able to implement a basic renderer in a few days, or even better, hours, without depending on two metric tons of XML ecosystem libraries. Bezier curves, elliptic curves, fills, outlines and gradients should mostly suffice to represent every unanimated SVG. An extension could allow animations in a separate file extension.
This minimal and well-delimited format could then have a strict test suite and be implemented in browsers and image viewers with relative ease. Users could rely on their graphic working everywhere and implementers wouldn't have to worry about implementing XLink, CSS and JavaScript as well. It could save bandwidth and computation power. Compilers from and to SVG could be written for compatibility.
It could be used as export format of user-facing programs like Inkscape or Adobe Illustrator. For people wanting to markup graphics through code there's already stuff like Ti*k*Z, [Haskell diagrams]( or [Python matplotlib]( that could also export to the new minimal interchange format.
I'm actually thinking about making a slim machine-focused vector graphics format (the name *"SlimSVG"* has been suggested :D) and writing my own human-focused Haskell graphics creation library with similar goals for my own purposes in the future, maybe as student research project for the university.
In summary: Decide whether a language is for humans or for machines and do one of those things. And do the one thing well instead of both, but badly.
[^i]: [Image source](, licensed under CC-BY-2.0
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment