specification VS wasm2ps

TinyVG follows the similar goals: an alternative to SVG with a specification which trades off features for simplicity. https://tinyvg.tech/

I wholehearedly agree with your point on information blackholes but I think the reason some people hate SVG is that they've had had to advanced things with or had to work with the spec and implement something around it. I haven't done so myself but I can tell pain when I read it.

Here is a mostly compatible alternative: https://tinyvg.tech/

I created a library to parse TinyVG files

After taking an interest in TinyVG I got to wondering if there is a similar idea just applied to conforming SVG files. Basically a format that includes nothing but basic paths, colors, gradients and a few shapes to make the implementation relatively easy to create.

If so, can you please make an issue in the specification repo: https://github.com/TinyVG/specification/

It's come up in discussions I've been in before, mostly with the PostScript document language, since you can run programs on your printer with PS, albeit incredibly slowly. I've written a roundabout C-to-printer compiler of sorts which compiles WASM code to PS, and it is admittedly even slower because it doesn't do much on the stack. But stack languages and linear logic have a pretty neat correspondence.

I'm not a fan of the usual uses of S-expressions in data formats, but for quite the opposite reasons. People seem to have a thing for making up new syntax, so you can't just throw a normal S-expression parser at the problem, and be done with it. For example, the wasm2ps reader [1] has to know how to read a comment in the WebAssembly text format. I decided to leave the project at handling integer instructions and control flow only, as there are other oddities like using a single atom for alignment and offsets in load and store instructions [2]. Some people I've talked to wished that people would stop inventing ad-hoc syntaxes, and just use S-expressions or something. Using S-expressions but adding more ad-hoc syntax gives you the worst of both options.

While admittedly less of a problem for implementation, it is also annoying to see lists with dangling parens on their own lines, and symbols with underscores or camelCase in the names, once you are used to the normal way of formatting Lisp code.

[1] https://github.com/no-defun-allowed/wasm2ps/blob/master/Code...