The fig format isn’t very human-editable. It has a few nice features that SVG doesn’t (e.g. concise pattern and arrow head styling, which have to be done separately and more explicitly in SVG, though on the other hand SVG gives you more flexibility), but its actual syntax is bluntly horrible. It’s mostly just a sequence of space-separated numbers, where some are enumerated values, some integer coordinates, some float coordinates, some integer sizes, some still other stuff; where some values change the syntax for subsequent lines; and there are two different sets of units intermingled, one defined in the document and the other in 80ths of an inch (… though it might just get thinned to 160ths of an inch, and is also defined as one screen pixel, whatever that means, given that it came from before the high-DPI era); and…
Just to explain the first line: 2: polyline or similar. 1: actually polyline. 0: solid line. 3: line is 3⁄80in thick. -1: default pen colour. 0: white fill (… but ignored because of “no fill” later). 0: depth (z-index). 0: unused. -1: no fill. 0.000: to do with dashes (not used because of “solid line” earlier). 0: mitre join. 0: butt cap. -1: radius (not used as this is an actual polyline). 1: forward arrow (so the next line must now define the arrow style). 0: no backward arrow. 2: two points (so on the third line it expects four numbers—x₁, y₁, x₂, y₂).
An inexact SVG paraphrase (most inexact because of the two different types of units, which SVG doesn’t fully or consistently have—the closest is vector-effect="non-scaling-vector"; also I will note that a number of the properties are the defaults and would thus be likely to be omitted in real life):
This is vastly more human-editable. I write SVG by hand regularly, and edit tool-assisted SVG by hand even more regularly. I could not do the same for Fig in a regular text editor—I’d want tooling that labelled every field and enumeration value.
Oh, let’s just take an example, a small excerpt from one of the diagrams at https://www.southampton.ac.uk/~dales/teaching/xfig/xfig.html:
Just to explain the first line: 2: polyline or similar. 1: actually polyline. 0: solid line. 3: line is 3⁄80in thick. -1: default pen colour. 0: white fill (… but ignored because of “no fill” later). 0: depth (z-index). 0: unused. -1: no fill. 0.000: to do with dashes (not used because of “solid line” earlier). 0: mitre join. 0: butt cap. -1: radius (not used as this is an actual polyline). 1: forward arrow (so the next line must now define the arrow style). 0: no backward arrow. 2: two points (so on the third line it expects four numbers—x₁, y₁, x₂, y₂).An inexact SVG paraphrase (most inexact because of the two different types of units, which SVG doesn’t fully or consistently have—the closest is vector-effect="non-scaling-vector"; also I will note that a number of the properties are the defaults and would thus be likely to be omitted in real life):
This is vastly more human-editable. I write SVG by hand regularly, and edit tool-assisted SVG by hand even more regularly. I could not do the same for Fig in a regular text editor—I’d want tooling that labelled every field and enumeration value.