6 ms·

I think it's ridiculous that SVG has a complexity comparable with HTML. With SVG you first have to parse the file into a DOM, because otherwise you can't reall

I think it's ridiculous that SVG has a complexity comparable with HTML. With SVG you first have to parse the file into a DOM, because otherwise you can't really apply CSS (for which you of course also need a parser). On this way you avoid all the common XML pitfalls like xml entities blowing up your memory. If you want to show animated SVGs you need a javascript implementation, because half the browsers don't understand the animate-elements. Being able to include javascript probably is the reason why most image hosters don't host SVGs. Javascript in SVG opens doors to all kind of evil things like cross site scripting. So you walk down your SVG DOM and begin to parse path data strings. The syntax seems understandable after a short while so you think you can easily write a parser. But the parser you'll write will be wrong because the details of the syntax are totally arcane, whitespace can sometimes be dropped (e.g. A.5.5.5 10.5.5 is the same as A 0.5 0.5 0.5 1 0 0.5 0.5), commas are allowed at some places but only one at most. Every program supporting SVG got this wrong at least once, and some like Inkscape still have a buggy parser. So you look up how to render this path and you see that you just have to render the border, but there are gazillions of options how to render borders you all have to support. So the next element you want to render is a text element, which is a huge joke because it doesn't even support multi-line text, but silly things like text whose baseline follows a path [1]. Because internationalisation is important SVG files of course can show different things depending on the locale [2]. So afterwards you just have to apply filters, which are basically half a pixel based image manipulation program [3]. I really don't see how adding new features makes any of this easier, when SVG 2.0 is basically a backwards-compatible superset. To proliferate vector graphics on the web we actually need a way simpler flat format. The only thing you actually really need is bezier paths and a way to fill them. [1] http://www.w3.org/TR/SVG11/text.html#TextOnAPath http://www.w3.org/TR/SVG11/text.html#TextOnAPath [2] http://www.w3.org/TR/SVG11/struct.html#ConditionalProcessing http://www.w3.org/TR/SVG11/struct.html#ConditionalProcessing [3] http://www.w3.org/TR/SVG11/filters.html http://www.w3.org/TR/SVG11/filters.html

vbezhenar 10y ago
The way I see it is SVG is a format for humans (that's why it got all those shapes and tricky formats) and its main use-case is browser (so CSS and JS support is not a problem, because it's already there). There should be another simpler vector format for machines, IMO.
- gulpahum 10y ago
  What would be the purpose of such a simpler vector format? Several formats already exist for various use cases: PDF for printing, SVG for web graphics (simple content and icons), OpenType fonts for vector based text and SVG as an exchange format between vector graphics apps. The only use case I can think of is for standalone vector graphics images, but PDF or SVG is often good enough for that.
  - vbezhenar 10y ago
    > What would be the purpose of such a simpler vector format? To allow simpler implementation for both consumer and creator software. To achieve better performance (lower size, faster parsing and drawing). > The only use case I can think of is for standalone vector graphics images, but PDF or SVG is often good enough for that. SVG has some problems as a graphics format, which are highlighted in this thread. I'm not sure about PDF, I never saw it used as a vector image format, so can't judge much about it.
    - userbinator 10y ago
      PDF's graphics are an optionally-compressed-binarily subset of PostScript, which manages to be both human-readable and relatively simple to parse.
  - legulere 10y ago
    The thing is, almost nobody is using SVGs on the Web. Usually wikipedia is cited as a website that uses them, when in reality they're rendering them to raster images. They actually have a nice site with the problems they're facing: https://commons.wikimedia.org/wiki/Help:SVG#Creating_SVG_images_for_Wikimedia_Commons https://commons.wikimedia.org/wiki/Help:SVG#Creating_SVG_ima... Other issues are that files might be bigger than pngs and have bad performance. PNG and JPEG files are also universally usable outside of browsers. Linux systems often use SVGs for icons, but that's basically where the support stops. If I want to include a SVG in a latex I have to convert it to postscript or pdf. If I want to include a SVG into a Word document I have to convert it into an emf (enhanced metafile). You can't use SVGs for cocoa, UIkit, WinForms or MFC applications out of the box. The reason probably is the complexity to support SVGs.
dietrichepp 10y ago
Many of your concerns are addressed by 2.0, go give it a look. > On this way you avoid all the common XML pitfalls like xml entities blowing up your memory. DTDs are gone, and with them, entity definitions. This particular attack is no longer possible in SVG 2.0. > So you walk down your SVG DOM and begin to parse path data strings. The syntax seems understandable after a short while so you think you can easily write a parser. But the parser you'll write will be wrong because the details of the syntax are totally arcane, whitespace can sometimes be dropped (e.g. A.5.5.5 10.5.5 is the same as A 0.5 0.5 0.5 1 0 0.5 0.5), commas are allowed at some places but only one at most. The data strings—sure, their syntax could be more natural, yes. But it's certainly not difficult to parse a data string if you pay close attention to the spec. These specs aren't the kind of thing that random programmers should be implementing anyway, you'll want a proper SVG library to parse the SVG for you, and the SVG library will come with a test suite. This is no different than the way we parse JSON or HTML—we farm it out to libraries because it's easy to get it wrong. But most text standards will produce a few broken implementations, SVG is no different. HTML parsers have disagreed since the beginning of time, there were recently some exploits for non-compliant URI parsers, and people have often forgotten the weird way you encode supplementary plane characters in JSON. Heck, if you look at "plain text" we can see a history of buggy programs, such as the NUL bytes that appeared in filenames for a buggy NFS server or the C0 AF directory traversal attack. > So the next element you want to render is a text element, which is a huge joke because it doesn't even support multi-line text… Multi-line text is a feature of SVG 2.0. > I really don't see how adding new features makes any of this easier, when SVG 2.0 is basically a backwards-compatible superset. 2.0 is not a superset. Again, you may want to take a look at the linked article at the top. Check out the section titled "Removed". It includes non-trivial chunks of functionality like the DTD, which vastly simplifies the parser. SVG fonts are also removed, which is a big chunk of complexity. Yes, if you're writing your own SVG parser, it can be a bit daunting, just like writing your own HTML parser. But removing the DTD and fonts is a win in terms of reduced complexity, and moving more attributes to styles reduce the complexity of making animations from the user's perspective. For me, SVG will continue to be an essential part of the web. Maybe you won't use it for "images" per se, at least not the way you embed JPEG and PNG files into your web pages, but you'll still be using it if you use D3 or the other cool drawing libraries for HTML. Canvas isn't always the right tool for the job. Or, put it this way. SVG isn't just an alternative to PNG, it's an alternative to <canvas>.
p0nce 10y ago
You are forgetting that you can't AFAIK embed custom fonts so using them exposes you to the different way OS handle font-weight, font-face and friends. Soon the only programs able to open SVG will be the browsers.
- aidos 10y ago
  Looking at the SVG2 spec it seems that support of embedded fonts is mandatory [1]. I'm not sure about the story in SVG. It's been supported wherever I've needed it and when parsing svg files myself I extract the fonts (which is easy enough with a simple grep / cut) [1] http://www.w3.org/TR/SVG2/styling.html#RequiredCSSFeatures http://www.w3.org/TR/SVG2/styling.html#RequiredCSSFeatures
  - p0nce 10y ago
    I've needed it in Adobe Illustrator SVG import, and did not wanted to exercise such CSS stuff. Now that I think of it, it may actually work.
    - aidos 10y ago
      Not sure what support is like in illustrator but the generation is super simple. You can base64 the font and embed it inline in a style tag.
jldugger 10y ago
While I agree that multiline text boxes would have been great, Text on a Path is also useful on occasion. What it comes down to is that if you look at SVG as vector graphics for the web, it's quite complicated, but if you look at it as part of replacing Adobe Illustrator, it may not yet have enough features. Certainly, you can't represent a circle perfectly with a bezier curve.
- viraptor 10y ago
  I didn't realise that and googled some more: https://math.stackexchange.com/questions/449035/is-it-possible-to-build-a-circle-with-quadratic-b%C3%A9zier-curves https://math.stackexchange.com/questions/449035/is-it-possib... Apparently "four cubic Bezier curves and gives an approximation whose maximum error is 0.0196% of the radius"
userbinator 10y ago
To proliferate vector graphics on the web we actually need a way simpler flat format. The only thing you actually really need is bezier paths and a way to fill them. The worst thing about this is, there was (and still is) one. It was invented by Macromedia 20 years ago and featured scalable vector graphics and animation in an extremely compact, easy-to-render format that worked great on the computers of the time. Later versions added interactivity and Turing-completeness, then Adobe bought them and it turned into a bit of a mess with all the security problems. I'm talking about Flash (SWF). If you ignore all the interactivity and Turing-complete features added to later versions, it is at its core an efficient and relatively simple vector graphics format. Because it's a binary format, parsing is far simpler and more constrained than with text. Too bad everyone only saw the downsides and shunned it, while the W3C kept pushing its SGML/XML/HTML-inspired formats...
- wmil 10y ago
  A W3C standard has to be open. Macromedia / Adobe used their EULAs and IP law to fight all third party swf renderers. Macromedia / Adobe thought they had something too valuable to share, so now it's dying. Also binary formats aren't as great as you think for vector formats that need to work between software written by different devs who don't have access to each other source code. Problems become very difficult to debug. EPS files are also text files.

vbezhenar 10y ago

The way I see it is SVG is a format for humans (that's why it got all those shapes and tricky formats) and its main use-case is browser (so CSS and JS support is not a problem, because it's already there). There should be another simpler vector format for machines, IMO.

gulpahum 10y ago
What would be the purpose of such a simpler vector format? Several formats already exist for various use cases: PDF for printing, SVG for web graphics (simple content and icons), OpenType fonts for vector based text and SVG as an exchange format between vector graphics apps. The only use case I can think of is for standalone vector graphics images, but PDF or SVG is often good enough for that.
- vbezhenar 10y ago
  > What would be the purpose of such a simpler vector format? To allow simpler implementation for both consumer and creator software. To achieve better performance (lower size, faster parsing and drawing). > The only use case I can think of is for standalone vector graphics images, but PDF or SVG is often good enough for that. SVG has some problems as a graphics format, which are highlighted in this thread. I'm not sure about PDF, I never saw it used as a vector image format, so can't judge much about it.
  - userbinator 10y ago
    PDF's graphics are an optionally-compressed-binarily subset of PostScript, which manages to be both human-readable and relatively simple to parse.
- legulere 10y ago
  The thing is, almost nobody is using SVGs on the Web. Usually wikipedia is cited as a website that uses them, when in reality they're rendering them to raster images. They actually have a nice site with the problems they're facing: https://commons.wikimedia.org/wiki/Help:SVG#Creating_SVG_images_for_Wikimedia_Commons https://commons.wikimedia.org/wiki/Help:SVG#Creating_SVG_ima... Other issues are that files might be bigger than pngs and have bad performance. PNG and JPEG files are also universally usable outside of browsers. Linux systems often use SVGs for icons, but that's basically where the support stops. If I want to include a SVG in a latex I have to convert it to postscript or pdf. If I want to include a SVG into a Word document I have to convert it into an emf (enhanced metafile). You can't use SVGs for cocoa, UIkit, WinForms or MFC applications out of the box. The reason probably is the complexity to support SVGs.

dietrichepp 10y ago

Many of your concerns are addressed by 2.0, go give it a look. > On this way you avoid all the common XML pitfalls like xml entities blowing up your memory. DTDs are gone, and with them, entity definitions. This particular attack is no longer possible in SVG 2.0. > So you walk down your SVG DOM and begin to parse path data strings. The syntax seems understandable after a short while so you think you can easily write a parser. But the parser you'll write will be wrong because the details of the syntax are totally arcane, whitespace can sometimes be dropped (e.g. A.5.5.5 10.5.5 is the same as A 0.5 0.5 0.5 1 0 0.5 0.5), commas are allowed at some places but only one at most. The data strings—sure, their syntax could be more natural, yes. But it's certainly not difficult to parse a data string if you pay close attention to the spec. These specs aren't the kind of thing that random programmers should be implementing anyway, you'll want a proper SVG library to parse the SVG for you, and the SVG library will come with a test suite. This is no different than the way we parse JSON or HTML—we farm it out to libraries because it's easy to get it wrong. But most text standards will produce a few broken implementations, SVG is no different. HTML parsers have disagreed since the beginning of time, there were recently some exploits for non-compliant URI parsers, and people have often forgotten the weird way you encode supplementary plane characters in JSON. Heck, if you look at "plain text" we can see a history of buggy programs, such as the NUL bytes that appeared in filenames for a buggy NFS server or the C0 AF directory traversal attack. > So the next element you want to render is a text element, which is a huge joke because it doesn't even support multi-line text… Multi-line text is a feature of SVG 2.0. > I really don't see how adding new features makes any of this easier, when SVG 2.0 is basically a backwards-compatible superset. 2.0 is not a superset. Again, you may want to take a look at the linked article at the top. Check out the section titled "Removed". It includes non-trivial chunks of functionality like the DTD, which vastly simplifies the parser. SVG fonts are also removed, which is a big chunk of complexity. Yes, if you're writing your own SVG parser, it can be a bit daunting, just like writing your own HTML parser. But removing the DTD and fonts is a win in terms of reduced complexity, and moving more attributes to styles reduce the complexity of making animations from the user's perspective. For me, SVG will continue to be an essential part of the web. Maybe you won't use it for "images" per se, at least not the way you embed JPEG and PNG files into your web pages, but you'll still be using it if you use D3 or the other cool drawing libraries for HTML. Canvas isn't always the right tool for the job. Or, put it this way. SVG isn't just an alternative to PNG, it's an alternative to <canvas>.

p0nce 10y ago

You are forgetting that you can't AFAIK embed custom fonts so using them exposes you to the different way OS handle font-weight, font-face and friends. Soon the only programs able to open SVG will be the browsers.

aidos 10y ago
Looking at the SVG2 spec it seems that support of embedded fonts is mandatory [1]. I'm not sure about the story in SVG. It's been supported wherever I've needed it and when parsing svg files myself I extract the fonts (which is easy enough with a simple grep / cut) [1] http://www.w3.org/TR/SVG2/styling.html#RequiredCSSFeatures http://www.w3.org/TR/SVG2/styling.html#RequiredCSSFeatures
- p0nce 10y ago
  I've needed it in Adobe Illustrator SVG import, and did not wanted to exercise such CSS stuff. Now that I think of it, it may actually work.
  - aidos 10y ago
    Not sure what support is like in illustrator but the generation is super simple. You can base64 the font and embed it inline in a style tag.

jldugger 10y ago

While I agree that multiline text boxes would have been great, Text on a Path is also useful on occasion. What it comes down to is that if you look at SVG as vector graphics for the web, it's quite complicated, but if you look at it as part of replacing Adobe Illustrator, it may not yet have enough features. Certainly, you can't represent a circle perfectly with a bezier curve.

viraptor 10y ago
I didn't realise that and googled some more: https://math.stackexchange.com/questions/449035/is-it-possible-to-build-a-circle-with-quadratic-b%C3%A9zier-curves https://math.stackexchange.com/questions/449035/is-it-possib... Apparently "four cubic Bezier curves and gives an approximation whose maximum error is 0.0196% of the radius"

userbinator 10y ago

To proliferate vector graphics on the web we actually need a way simpler flat format. The only thing you actually really need is bezier paths and a way to fill them. The worst thing about this is, there was (and still is) one. It was invented by Macromedia 20 years ago and featured scalable vector graphics and animation in an extremely compact, easy-to-render format that worked great on the computers of the time. Later versions added interactivity and Turing-completeness, then Adobe bought them and it turned into a bit of a mess with all the security problems. I'm talking about Flash (SWF). If you ignore all the interactivity and Turing-complete features added to later versions, it is at its core an efficient and relatively simple vector graphics format. Because it's a binary format, parsing is far simpler and more constrained than with text. Too bad everyone only saw the downsides and shunned it, while the W3C kept pushing its SGML/XML/HTML-inspired formats...

wmil 10y ago
A W3C standard has to be open. Macromedia / Adobe used their EULAs and IP law to fight all third party swf renderers. Macromedia / Adobe thought they had something too valuable to share, so now it's dying. Also binary formats aren't as great as you think for vector formats that need to work between software written by different devs who don't have access to each other source code. Problems become very difficult to debug. EPS files are also text files.