1. 36
  1.  

  2. 16

    From the existing formats section:

    SVG is really an application SDK that happens to include vector graphics (e.g. fully supporting SVG involves supporting XML, JS, DOM, SMIL, HTML, audio playback, keyboard, mouse, and touch input, form controls, HTTP submission, video conferencing, etc). Additionally, there is no clearly defined subset of SVG to target if one only wants “vector graphics”: the modern version of SVG Tiny involves supporting JavaScript and video playback, while the original version of SVG Tiny requires an unusual subset of features, for example it does not support gradients, but does support custom fonts.

    PDF has developed into an electronic document exchange format that happens to include vector graphics (e.g. fully supporting PDF involves supporting multipage documents, form controls, video, 3D, digital signatures, etc).

    1. 5

      That bit about SVG and SVG Tiny was fascinating - I hadn’t fully grokked how inappropriate that spec is for simple vectors.

      1. 4

        SVG is the poster child for the everything-is-XML movement from the late ‘90s / early 2000s. The group wanted to have a set of declarative, composeable, file formats. The down side of making composition so easy is that it makes subsetting hard. SVG didn’t want to define a new way of embedding rich text because XHTML / CSS already existed, but now any SVG renderer needs to support all of XHTML and CSS to get the text right. In practice, most SVG generators will use a tiny subset of XHTML, but it may not be quite the same subset that your viewer supports.

        SVG is a pretty horrible format. It’s sufficiently XML to be verbose and annoying to work with, but not quite XML enough that you can work with it in a uniform way. For example, paths in a pure XML format would be defined as nested elements containing coordinates and attributes. This would be horribly verbose (though very much amenable to compression) but would give a uniform object model representing the document. Instead, SVG provides path element that has a d attribute that contains something that looks a lot like a PostScript command sequence embedded as text (it may be PostScript, I’m not sure). You need to update this via string processing, not via DOM manipulations. This also makes animations annoying because you can’t do generic things like moving a point in a line and telling the rendering framework to animate the changes, you have to keep rewriting the text and telling it to redraw. You get to combine the worst aspects of a declarative API with the worst aspects of an imperative one.

        1. 1

          I normally don’t connect with complaints about SVG, but this description of path and why it is horrible is spot on.

    2. 1

      I like the design goals. Even in the context of Flutter, they maintain a certain KISS philosophy.