Understanding parsing SVG file format

Question

First off, gist here

Map.svg in the gist is the original Map I'm working with, got it off wikimedia commons.

Now, there is a land mass off the eastern cost of Texas in that original svg. I removed it using Inkscape, and it re-wrote the path in a strange new way. The diff is included in the gist.

Now this new way of writing the path blows up my parser logic, and I'm trying to understand what happened. I'm hoping someone here knows more about the SVG file format that I do. I will admit I have not read through the entire SVG standard spec, however the parts of it I did read didn't mention anything about missing commands or relative coordinates. Then again I may have been looking at the incorrect spec, not sure.

The way I understood it, SVG path data was very straight forward, something like this:

(M,L,C)[point{n}] .... [Z] then repeat ad-nauseum

Now the part I'm trying to understand is this new Inkscape has written out what seems like relative coordinates, without commands like L, or L being implied somehow. My gut is telling me what has happened here is obvious to someone. For what it's worth I'm doing my parsing in C.

Answer 1

If you're parsing SVG, why not look at the SVG specification?

Start a new sub-path at the given (x,y) coordinate. M (uppercase) indicates that absolute coordinates will follow; m (lowercase) indicates that relative coordinates will follow. If a moveto is followed by multiple pairs of coordinates, the subsequent pairs are treated as implicit lineto commands.

From: http://www.w3.org/TR/2011/REC-SVG11-20110816/paths.html#PathDataMovetoCommands

You said,

The way I understood it, SVG path data was very straight forward, something like this: (M,L,C)[point{n}] .... [Z]

I don't know where you got that information. Stop getting your information from that source.

I will admit I have not read through the entire SVG standard spec...

Nobody reads the entire spec. Just focus on the part you're implementing at the moment. You could also start with SVG Tiny, and work with that subset for now.

Path Grammar is where you should start when writing a parser. If you can't read it, then buy a book on compilers.

Path grammar: http://www.w3.org/TR/2011/REC-SVG11-20110816/paths.html#PathDataBNF