[paul_manias]

> Oh. You can almost hear the designer saying "well fuck it, we'll just jam it all into a string.

I'll throw in my 2 cents here because the responses aren't addressing why the path descriptors are stylised in this way. Whether SVG's underlying document format was XML, JSON, SGML, CSS or whatever is irrelevant. However else you did it, any alternative would be more verbose because the 'd' tag already offers the most compact way of describing vector paths in text form.

And that's the point - it's small. Even in this compact form, it's not unusual for path strings to reach kilobytes in length when floating point numbers are catered for. Thus we need the path descriptions to be as small as possible for optimal parsing of the file and keeping the file size down.

As a side-note I disagree with the author's conjecture that SVG doesn't succeed as a machine-focused language or a human-focused language. I think it serves both sides of the coin quite well in practice (certainly more-so than HTML) and a pared back version already exists in the form of SVG Tiny.

[felixfbecker]

I wonder though why does that matter for a web format that can be served with GZIP encoding? Wouldn't GZIP eat the duplicative <move-to /> tags for breakfast? It would be so much easier to write, read, manipulate and animate.

[paul_manias]

Let's imagine for a moment that path instructions could be mapped out with more verbose instructions. Would this really get enough practical use to be worthy of standardisation?

For the most part, SVG path outlines are almost always defined in software like Illustrator and Inkscape. Bezier curves are beyond the average person's ability to create or modify without visual aids. Simple path constructs aren't all that common in practice and the examples I see posted here aren't representative of real-world use.

SVG does provide transform capabilities to move, rotate and scale paths easily, and those features can be applied within a text editor. For anything else there are plenty of visual tools to aid path modification. Personally I've modified many an SVG file manually, but when it comes to the paths I can't say that seeing them laid bare would be of a help to my workflow.

[samatman]

I'll reference you to a comment elsewhere in the tree, and its parents[0], which came up with this s-expression:

    (path (M 10 10 H 90 V 90 H 10 L 10 10) :color red)

It's legitimately hard to beat sexprs for the combination of compactness, generality, and ease of use. If I were to start from first principles in making a vector graphics format, I'd probably make it a schema over EDN. I bet the extra complexity of having explicit maps and vectors would pay off.

[0]: https://news.ycombinator.com/item?id=26118727

[paul_manias]

I think that's reasonable, but is syntactic sugar really going to help you modify a path when the vector points will look more like this in reality:

  (path (M 368.296, 1.514) (c -0.908, 0 -1.818, 0.011 -2.716, 0.021) 
  (c 0.053, 0, 0.106, 0, 0.159,0) (c 147.196, 0.836, 265.306, 94.672, 267.029, 183.784)
  (c 0, 0.581, 0.065, 35.087, 0.065, 35.087) (h 49.415)
  (v -33.471) (h 37.094) (v -31.376)
  (C 719.342, 77.099, 575.826, 1.514, 368.296, 1.514)
  (z))

[RobertKerans]

I've used SVG pretty heavily for years, in particular for the last couple of months as I've been writing libraries/tools that render SVG output (parsing for the cli tool side, lots of hand-writing & testing, cleaning, rendering).

Yes an s-expression is imo normally the best representation (more specifically, an x-expression (see Racket) would be ideal). However, practically, it's not actually that useful. It is very useful as an intermediary step.

For example for a tool where the SVG is parsed to an x-expression and cleaned then compiled back. This is one of the [aborted] things I was working on, as the three best existing tools [in JS, Python and Rust] for this all have issues of one kind or another. Or you have a tool that allows you to write x-expressions then compile. But always with this, if that's the case, can't really directly jnterop with the host language/platform -- as you say, would have to be from first principles. And further to that, it would need HTML from first principles because one of the huge, huge benefits is that SVG drops directly into HTML with virtually the same semantics, same styling, same JS interactivity hooks. And the issue is compounded by SVG not just being XML, that it is also a DSL (NB solution is normally to restrict to a subset of features), so the clean structure breaks down pretty often. Imo SVG has to be the way it is, that the tradeoffs of the bastardised XML it uses have to have been made for it to be actually useful. Those tradeoffs also make it difficult to use, and often very difficult to parse easily. But without changing how HTML works, how web browser rendering works, I don't see how there are any alternatives that are substantially better.

[samatman]

I think the other desiderata mentioned in the original post are more important than choice of serialization format. SVG already exists, and we're kind of stuck with it. There are other applications where having a better-designed vector graphics format might pay off, and tying it to the browser all over again wouldn't be a win.

At that point, using an s-expression format (x-expression, EDN, I'm agnostic) should be the first choice. One of the first things that would have to be implemented, of course, is a translator to SVG.

My interest in vector graphics is such that, on the few occasions I need them, I just shrug and deal with the format we have.