Reputation: 20940
I'm working on a project where I need to parse svg path data.
Right now we're loading an svg, looking for the path
tag, and pulling out it's d
attribute.
For some of the artwork we'll get path data that is made up of coordinates which we can translate into the data types we need. E.g.
But other times the d
value is in a more g-code-esq format.
Like in this case I drew a rectangle, converted it to a compound path:
And when I export it and look at the svg I get a d
value like this:
Which we can't easily parse for the project.
My questions are:
I know that this seems like more of an art question than a programming question, but I'm trying to understand the underlying reasoning behind the svg data structure so I can better parse it.
Upvotes: 1
Views: 620
Reputation: 20940
Oh! Oh ok, I was 100% misunderstanding the path data that I was reading. I didn't realize that the delimiting information was based on the letter. My brain wanted some specific character as a delimiter like a comma or pipe.
So reading (and in some cases re-reading :| ) the documentation, when I see:
M753,315H435.27V165H753Z
I can read that as:
M753,315
Move to x,y coordinates x: 753 y:315
H435.27
Starting at the current location, draw a horizontal line to the absolute x
coordinate of 435.27
V165
Starting at the current location, draw a vertical line to the absolute y
coordinate of 165
H753
Starting at the current location, draw a horizontal line to the absolute x
coordinate of 753
Z
Draw a straight line to the initial point of this path to close the path. This doesn't necessarily mean a horizontal or vertical line, but the coincidence that we're at the same x
coordinate that we started at means that if we draw a straight line we will get a vertical line to complete the rectangleThat seems right. Anything I missed or misunderstood?
Also, thank for all of the links. I appreciate the points :clap: :bows:
Upvotes: 3