SVG really is just an awful format. What the market wanted was a clean, easily parseable specification for vector image data based on a solid rendering specification. What it got was an extensible HTML-like scripting language where all the vector stuff was ad hoc and poorly implemented, and where (this is the bit that absolutely drives me up the wall) the actual image data is not stored in the metadata format they chose. You have to parse this entirely different string format if you want to extract the points on your curve or whatever!
To be fair the format was invented in an era before gzip compression. The very compact format and silly attribute names like d are from optimizing for that.
Not sure I've heard that angle before. I'm tempted to agree, but then the choice of *xml* as the enclosing format argues strongly that efficiency wasn't at the forefront of the design criteria.
Also the dates don't work. HTTP/1.1 with gzip/compress/deflate encodints was live in browsers and servers with inline compression well before the standard was published in RFC 2068 in 1997. SVG's spec was four years behind that, and IIRC adoption being pretty glacial as far as completeness and compliance.
Comments
SVG really is just an awful format. What the market wanted was a clean, easily parseable specification for vector image data based on a solid rendering specification. What it got was an extensible HTML-like scripting language where all the vector stuff was ad hoc and poorly implemented, and where (this is the bit that absolutely drives me up the wall) the actual image data is not stored in the metadata format they chose. You have to parse this entirely different string format if you want to extract the points on your curve or whatever!
To be fair the format was invented in an era before gzip compression. The very compact format and silly attribute names like d are from optimizing for that.
Not sure I've heard that angle before. I'm tempted to agree, but then the choice of *xml* as the enclosing format argues strongly that efficiency wasn't at the forefront of the design criteria.
Also the dates don't work. HTTP/1.1 with gzip/compress/deflate encodints was live in browsers and servers with inline compression well before the standard was published in RFC 2068 in 1997. SVG's spec was four years behind that, and IIRC adoption being pretty glacial as far as completeness and compliance.