4 ms·

SVG is a complex format, but it's not that bad compared to other widely adopted standards. Just for comparison: - SVG 1.1 - 826 pages (http://www.w3.org/TR/SVG

SVG is a complex format, but it's not that bad compared to other widely adopted standards. Just for comparison: - SVG 1.1 - 826 pages (http://www.w3.org/TR/SVG/REC-SVG11-20110816.pdf http://www.w3.org/TR/SVG/REC-SVG11-20110816.pdf) - HTML 5 - 1156 pages (https://html.spec.whatwg.org/print.pdf https://html.spec.whatwg.org/print.pdf) - ODF 1.2 - 1217 pages (https://www.oasis-open.org/standards#opendocumentv1.2 https://www.oasis-open.org/standards#opendocumentv1.2) - PDF 1.7 - 1310 pages (http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/pdf_reference_1-7.pdf http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdf...) SVG 2 spec is even smaller because it removes sections that are either duplicating other W3C standards (filters, styling) or not implemented by all major vendors (animations, fonts, path APIs).

legulere 11y ago
You forgot that it also requires XML and CSS. I'm surprised PDF is just marginally bigger, considering that it's carrying around lots of legacy stuff is so much more than just a vector graphics format. Anyway. SVG is not or only partly competing with the formats you listed. It's actually a format that's supposed to be included in those formats you listed. It's competing with PNG 81 Pages (http://www.w3.org/TR/REC-png.pdf http://www.w3.org/TR/REC-png.pdf) or EPS 31 Pages (http://partners.adobe.com/public/developer/en/ps/5002.EPSF_Spec.pdf http://partners.adobe.com/public/developer/en/ps/5002.EPSF_S... which is kind of cheated though because it requires the ~800 page postscript specification, at least it doesn't need XML and CSS additionally) Removing sections that are standardized somewhere else doesn't make a file format easier, especially if you want to implement it outside of a browser. There's still tons of features in SVG that are probably not used or not really needed: Mandating IEE 754 binary floating point coordinates, while representing them as decimals that are usually rounded to 0.001 or 0.0001. This causes rounding errors all the time. The 16.16 fixed point format used in ttf seems more sensible for this usecase. Including (parts of) external SVGs with <use>. <use> doesn't seem to be supported in Safari, Firefox or Inkscape anyway. <switch> to make an SVG render differently on computers with different locale. ARIA (accessibility) support, what happened to a description of the image? Commas as optional separators in paths, but only at certain locations and only at most one of them. There have been several bugs in programs using SVG concerning the parsing path strings that were related to white space. Basic shapes that can just as easily can be constructed using <path>, especially the polygon and polyline. The total absurdity that is <text>. Text usually isn't the main content of images, yet the chapter about text is the longest in the SVG specification, containing stuff like text flowing along a path. And all this without supporting multi-line text. Just use <path> instead, bitmap graphics also uses rasterized text. If fonts aren't installed it may cause overlapping, or it might not get rendered at all.
- jarek-foksa 11y ago
  XML dependence will become optional in SVG 2 and hopefully it will be deprecated in SVG 3. Chrome team is already considering switching to HTML parser no matter whether the SVG document uses XML or HTML serialization. <use> elements with external references are tricky due to the same origin policy restrictions and various browser bugs, but referencing local IDs works just fine. Inkscape for example creates clones and symbol instances with <use> elements. The most obscure part of the paths specification, i.e. the pathSegList interface, is gone in SVG 2. There were some plans to deprecate the "d" attribute and instead introduce a nicer function-based syntax such as data="move(10, 10) line(20, 20)", but AFAIK this idea has been dropped. Still, the path data grammar is clearly defined in the spec, I'm not sure why browser vendors don't follow it. SVG 2 will support multi-line text and embedded WOFF fonts. This feature is important when you are authoring e.g. UI mockups or posters. Even low level drawing APIs such as canvas have the text primitive. If you express textual content with <path> instead of <text> element then it will not be editable and selectable, screenreaders won't recognize it and search engines won't index it.

legulere 11y ago

You forgot that it also requires XML and CSS. I'm surprised PDF is just marginally bigger, considering that it's carrying around lots of legacy stuff is so much more than just a vector graphics format. Anyway. SVG is not or only partly competing with the formats you listed. It's actually a format that's supposed to be included in those formats you listed. It's competing with PNG 81 Pages (http://www.w3.org/TR/REC-png.pdf http://www.w3.org/TR/REC-png.pdf) or EPS 31 Pages (http://partners.adobe.com/public/developer/en/ps/5002.EPSF_Spec.pdf http://partners.adobe.com/public/developer/en/ps/5002.EPSF_S... which is kind of cheated though because it requires the ~800 page postscript specification, at least it doesn't need XML and CSS additionally) Removing sections that are standardized somewhere else doesn't make a file format easier, especially if you want to implement it outside of a browser. There's still tons of features in SVG that are probably not used or not really needed: Mandating IEE 754 binary floating point coordinates, while representing them as decimals that are usually rounded to 0.001 or 0.0001. This causes rounding errors all the time. The 16.16 fixed point format used in ttf seems more sensible for this usecase. Including (parts of) external SVGs with <use>. <use> doesn't seem to be supported in Safari, Firefox or Inkscape anyway. <switch> to make an SVG render differently on computers with different locale. ARIA (accessibility) support, what happened to a description of the image? Commas as optional separators in paths, but only at certain locations and only at most one of them. There have been several bugs in programs using SVG concerning the parsing path strings that were related to white space. Basic shapes that can just as easily can be constructed using <path>, especially the polygon and polyline. The total absurdity that is <text>. Text usually isn't the main content of images, yet the chapter about text is the longest in the SVG specification, containing stuff like text flowing along a path. And all this without supporting multi-line text. Just use <path> instead, bitmap graphics also uses rasterized text. If fonts aren't installed it may cause overlapping, or it might not get rendered at all.

jarek-foksa 11y ago
XML dependence will become optional in SVG 2 and hopefully it will be deprecated in SVG 3. Chrome team is already considering switching to HTML parser no matter whether the SVG document uses XML or HTML serialization. <use> elements with external references are tricky due to the same origin policy restrictions and various browser bugs, but referencing local IDs works just fine. Inkscape for example creates clones and symbol instances with <use> elements. The most obscure part of the paths specification, i.e. the pathSegList interface, is gone in SVG 2. There were some plans to deprecate the "d" attribute and instead introduce a nicer function-based syntax such as data="move(10, 10) line(20, 20)", but AFAIK this idea has been dropped. Still, the path data grammar is clearly defined in the spec, I'm not sure why browser vendors don't follow it. SVG 2 will support multi-line text and embedded WOFF fonts. This feature is important when you are authoring e.g. UI mockups or posters. Even low level drawing APIs such as canvas have the text primitive. If you express textual content with <path> instead of <text> element then it will not be editable and selectable, screenreaders won't recognize it and search engines won't index it.