4 ms·

SVG Path Strings

72 points by 1wheel 12y ago

jessedhillon 12y ago
I have never understood why, when it comes to the <path> element, the entire definition of the path is shoved into one plain text attribute with its own specification language. Why couldn't there have been special nodes like <curve> <move> etc so that the path can be processed using standard DOM traversal? As it is, anyone using paths in a programmatic way will invariably end up writing error-prone parsing and composing logic to modify the `d` attribute. What am I missing? This seems like a major area for improvement.
- nothrabannosir 12y ago
  I was writing this exact reply. This has been bugging me forever. When reading SVG, you suddenly need to write two parsers. The only reason I can think of is that the resulting file would end up too bloated. But if that was really the reason, why did nobody say: wow, then maybe XML is not the right language for this? That would be the W3C admitting XML is not the right tool, but stubbornly sticking to it, anyway. Unfathomable. There has to be another reason.
  - tom9729 12y ago
    From the spec: "The syntax of path data is concise in order to allow for minimal file size and efficient downloads, since many SVG files will be dominated by their path data. " http://www.w3.org/TR/SVG11/paths.html http://www.w3.org/TR/SVG11/paths.html
    - jessedhillon 12y ago
      So then, "we'll just use XML except where it would be most useful"
      - ygra 12y ago
        It'd be a list, in a document format for tree-like structures. You cannot nest path commands, it doesn't really make that much sense to have individual elements for them. In any case, if it bothers you that much, writing an XSLT that takes path elements and transforms them into the path data syntax shouldn't be that hard.
- aidos 12y ago
  I quite like it. And actually, if you think about it - they're semantically different. In one case you're dealing if a set of different elements, in another you have the definition of a single shape. More than that though, I work with large svgs and if there were dom nodes for all of the components, nothing would be able to render them :)
  - dperfect 12y ago
    > if there were dom nodes for all of the components, nothing would be able to render them Once the components are parsed into whichever data structure is used internally (by the rendering library), wouldn't the memory and processing footprint be the same either way? I do agree, it would make the files much larger, but as pointed out in another comment, that should be a clear indication that XML simply isn't a good fit for this use case. btw - I use SVG a fair amount myself, and have written my own path parser and builder recently. While it's not inherently too difficult, is definitely is annoying, especially when the format of the file (XML) should be able to accommodate the path components. Semantically, if child nodes can be used for composition (e.g., a document element with child nodes that describe the document contents), then I don't see how any SVG <shape> should be different.
    - aidos 12y ago
      I don't know the inner workings of it, but in web browsers the number of DOM nodes end up being the limiting factor when you're dealing with large SVGs. I guess because there are so many extra objects and everything needs to be tracked / event handling etc. If you were writing to a one way rendering to a surface I guess things would be different. You could use a group full of individual paths, and call that a single shape, but it's not really a single shape. I know I'm just splitting hairs, but the DOM node thing is a bit of a problem for me. PS I do think having two languages is a little bit silly really, but I don't mind that much
      - 1wheel 12y ago
        > in web browsers the number of DOM nodes end up being the limiting factor Yup. Each node comes with a significant amount of overhead. If every lineto command required a separate node, this map[1] would go from requiring a manageable ~3000 nodes to a laggy ~40000. I ran into this while working on a population map[2]. To draw paths with variable stroke, I initially tried creating a path element for segments of different strokes. This was too slow to animate or even render without freezing the browser, so I ended drawing the path left to right then right to left, making the height offset smaller and larger to simulate a stroke. [1]http://bl.ocks.org/mbostock/5925375/ http://bl.ocks.org/mbostock/5925375/ [2]http://roadtolarissa.com/population-division/ http://roadtolarissa.com/population-division/
Uehreka 12y ago
I'm getting some real Baader-Meinhof here. I just started making SVG path animations at work and just checked them into mainline today. I like the look of this tutorial, and I hope you make some more in-depth ones. Piling through W3C specs is no fun, and I could really use some good tutorials for when I need to get co-workers up to speed on SVG.
- bshimmin 12y ago
  For anyone else thinking, "Uh, wasn't Baader-Meinhof a pretty decent German film from a few years back?", this might help you: http://www.damninteresting.com/the-baader-meinhof-phenomenon/ http://www.damninteresting.com/the-baader-meinhof-phenomenon...
  - jameshart 12y ago
    For anyone else thinking, "Uh, wasn't Baader-Meinhof a far-left German terrorist organization from the early 1970s?", this might help you: http://www.imdb.com/title/tt0765432/ http://www.imdb.com/title/tt0765432/
    - bshimmin 12y ago
      Well, you'd think anyone who'd seen the film and thought it was decent would remember it was a far-left German terrorist organisation! I feel like we may have digressed.
jameshart 12y ago
Am I missing some sort of mathematical simplicity in the elliptical arc specification, because it looks like an absolute mess; surely there must be some mechanism that allows you to specify an elliptical arc between two points using tangent definitions, bezier-style. As it is, there's a real mess there where rotating the end point around the start point, you have to rotate the elliptical axis in the opposite direction to maintain the same curve. It looks like its one optimal scenario is in creating a rounded corner, which I guess is the common use case - but the unpredictability of how the curve changes if you move the end points without adjusting the corner radii seems to be a significant downside.
- 1wheel 12y ago
  The implementations notes list another potential specification[1]. I'm guessing it was avoided because it wouldn't follow the pattern of ending each command with the new coordinates of the pen. They were definitely considering the rounded corners use case; the details of drawing a rect element with a path[2] make arcs sound much easier to use than they actually are most of the time. [1]http://www.w3.org/TR/SVG/implnote.html#ArcParameterizationAlternatives http://www.w3.org/TR/SVG/implnote.html#ArcParameterizationAl... [2]http://www.w3.org/TR/SVG/shapes.html#RectElement http://www.w3.org/TR/SVG/shapes.html#RectElement
- ygra 12y ago
  I constantly have to look up the arc syntax in the spec, actually. It also has other shortcomings, e.g. having the same start and end point does not work. To draw a whole ellipse you need two arcs. SVG 2 has it on the roadmap to simplify arcs for manual writing. Not that it's going to be finished soon, though.

72 points by 1wheel 12y ago

I have never understood why, when it comes to the <path> element, the entire definition of the path is shoved into one plain text attribute with its own specification language. Why couldn't there have been special nodes like <curve> <move> etc so that the path can be processed using standard DOM traversal? As it is, anyone using paths in a programmatic way will invariably end up writing error-prone parsing and composing logic to modify the `d` attribute. What am I missing? This seems like a major area for improvement.

nothrabannosir 12y ago
I was writing this exact reply. This has been bugging me forever. When reading SVG, you suddenly need to write two parsers. The only reason I can think of is that the resulting file would end up too bloated. But if that was really the reason, why did nobody say: wow, then maybe XML is not the right language for this? That would be the W3C admitting XML is not the right tool, but stubbornly sticking to it, anyway. Unfathomable. There has to be another reason.
- tom9729 12y ago
  From the spec: "The syntax of path data is concise in order to allow for minimal file size and efficient downloads, since many SVG files will be dominated by their path data. " http://www.w3.org/TR/SVG11/paths.html http://www.w3.org/TR/SVG11/paths.html
  - jessedhillon 12y ago
    So then, "we'll just use XML except where it would be most useful"
    - ygra 12y ago
      It'd be a list, in a document format for tree-like structures. You cannot nest path commands, it doesn't really make that much sense to have individual elements for them. In any case, if it bothers you that much, writing an XSLT that takes path elements and transforms them into the path data syntax shouldn't be that hard.
aidos 12y ago
I quite like it. And actually, if you think about it - they're semantically different. In one case you're dealing if a set of different elements, in another you have the definition of a single shape. More than that though, I work with large svgs and if there were dom nodes for all of the components, nothing would be able to render them :)
- dperfect 12y ago
  > if there were dom nodes for all of the components, nothing would be able to render them Once the components are parsed into whichever data structure is used internally (by the rendering library), wouldn't the memory and processing footprint be the same either way? I do agree, it would make the files much larger, but as pointed out in another comment, that should be a clear indication that XML simply isn't a good fit for this use case. btw - I use SVG a fair amount myself, and have written my own path parser and builder recently. While it's not inherently too difficult, is definitely is annoying, especially when the format of the file (XML) should be able to accommodate the path components. Semantically, if child nodes can be used for composition (e.g., a document element with child nodes that describe the document contents), then I don't see how any SVG <shape> should be different.
  - aidos 12y ago
    I don't know the inner workings of it, but in web browsers the number of DOM nodes end up being the limiting factor when you're dealing with large SVGs. I guess because there are so many extra objects and everything needs to be tracked / event handling etc. If you were writing to a one way rendering to a surface I guess things would be different. You could use a group full of individual paths, and call that a single shape, but it's not really a single shape. I know I'm just splitting hairs, but the DOM node thing is a bit of a problem for me. PS I do think having two languages is a little bit silly really, but I don't mind that much
    - 1wheel 12y ago
      > in web browsers the number of DOM nodes end up being the limiting factor Yup. Each node comes with a significant amount of overhead. If every lineto command required a separate node, this map[1] would go from requiring a manageable ~3000 nodes to a laggy ~40000. I ran into this while working on a population map[2]. To draw paths with variable stroke, I initially tried creating a path element for segments of different strokes. This was too slow to animate or even render without freezing the browser, so I ended drawing the path left to right then right to left, making the height offset smaller and larger to simulate a stroke. [1]http://bl.ocks.org/mbostock/5925375/ http://bl.ocks.org/mbostock/5925375/ [2]http://roadtolarissa.com/population-division/ http://roadtolarissa.com/population-division/

Uehreka 12y ago

I'm getting some real Baader-Meinhof here. I just started making SVG path animations at work and just checked them into mainline today. I like the look of this tutorial, and I hope you make some more in-depth ones. Piling through W3C specs is no fun, and I could really use some good tutorials for when I need to get co-workers up to speed on SVG.

bshimmin 12y ago
For anyone else thinking, "Uh, wasn't Baader-Meinhof a pretty decent German film from a few years back?", this might help you: http://www.damninteresting.com/the-baader-meinhof-phenomenon/ http://www.damninteresting.com/the-baader-meinhof-phenomenon...
- jameshart 12y ago
  For anyone else thinking, "Uh, wasn't Baader-Meinhof a far-left German terrorist organization from the early 1970s?", this might help you: http://www.imdb.com/title/tt0765432/ http://www.imdb.com/title/tt0765432/
  - bshimmin 12y ago
    Well, you'd think anyone who'd seen the film and thought it was decent would remember it was a far-left German terrorist organisation! I feel like we may have digressed.

jameshart 12y ago

Am I missing some sort of mathematical simplicity in the elliptical arc specification, because it looks like an absolute mess; surely there must be some mechanism that allows you to specify an elliptical arc between two points using tangent definitions, bezier-style. As it is, there's a real mess there where rotating the end point around the start point, you have to rotate the elliptical axis in the opposite direction to maintain the same curve. It looks like its one optimal scenario is in creating a rounded corner, which I guess is the common use case - but the unpredictability of how the curve changes if you move the end points without adjusting the corner radii seems to be a significant downside.

1wheel 12y ago
The implementations notes list another potential specification[1]. I'm guessing it was avoided because it wouldn't follow the pattern of ending each command with the new coordinates of the pen. They were definitely considering the rounded corners use case; the details of drawing a rect element with a path[2] make arcs sound much easier to use than they actually are most of the time. [1]http://www.w3.org/TR/SVG/implnote.html#ArcParameterizationAlternatives http://www.w3.org/TR/SVG/implnote.html#ArcParameterizationAl... [2]http://www.w3.org/TR/SVG/shapes.html#RectElement http://www.w3.org/TR/SVG/shapes.html#RectElement
ygra 12y ago
I constantly have to look up the arc syntax in the spec, actually. It also has other shortcomings, e.g. having the same start and end point does not work. To draw a whole ellipse you need two arcs. SVG 2 has it on the roadmap to simplify arcs for manual writing. Not that it's going to be finished soon, though.