[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.