FIG File Documentation


Summary

A .fig file is an Xfig Drawing, the native vector-graphics format of the open-source Xfig editor on Unix and Linux. It is plain ASCII text: the file opens with a #FIG 3.2 version line, followed by a header and a list of drawing objects (lines, ellipses, splines, arcs and text) encoded as numeric records. You can read it in any text editor, edit it in Xfig, and convert it to SVG, PDF or EPS with fig2dev. Its MIME type is image/x-xfig.

Technical details

FeatureValue
Full nameXfig Drawing
File extension.fig
MIME typeimage/x-xfig
Format typePlain-text vector graphics (2D drawing)
DeveloperXfig project (open source; originated at UC Berkeley / Supoj Sutanthavibul)
Current format versionFIG 3.2 (older 3.1, 3.0, 2.1, 1.4 exist)
EncodingASCII / UTF-8 text, line-based
Magic / first line#FIG 3.2 (version header line)
Coordinate unitsFig units; default resolution 1200 Fig units per inch
Coordinate originUpper-left (coord_system 2)
Object type codes0 colour, 1 ellipse, 2 polyline, 3 spline, 4 text, 5 arc, 6 compound
Native editorXfig (Unix/Linux/X11); WinFIG on Windows; jfig (Java)
Export toolfig2dev / Transfig
Exports toSVG, PDF, EPS, PostScript, PNG, LaTeX/PSTricks
Related extensions.svg, .eps, .pdf, .png
Also seen asFigma design file, MATLAB figure (unrelated formats sharing the extension)
Open standardYes (open, documented format)
SpecificationFIG format 3.2
Syntax at a glance

An Xfig file is line-based ASCII text. The first line is the version string #FIG 3.2. A fixed header follows: a line giving orientation (Landscape/Portrait), justification, units (Metric/Inches), papersize, export magnification, Single/Multiple page and a transparent color code, then a line with the resolution and coord_system (typically 1200 2 — 1200 Fig units per inch, upper-left origin). After the header comes one record per drawing object, each introduced by an integer object code: 0 colour pseudo-object, 1 ellipse, 2 polyline, 3 spline, 4 text, 5 arc, 6 compound (grouping). Lines beginning with # are comments.

What is a FIG file?

A .fig file is an Xfig Drawing, the native document format of Xfig, an interactive 2D vector-drawing editor that has run on Unix and the X Window System since the late 1980s (the program grew out of work by Supoj Sutanthavibul at the University of Texas and has been maintained as open source ever since). Unlike most graphics formats, a .fig file is plain, human-readable ASCII text. Every shape in the drawing is stored as a line or two of integers and floats, which means you can read, diff and even hand-edit a .fig in an ordinary text editor.

The extension is shared by unrelated formats — a Figma design file and a MATLAB figure both use .fig — but those are binary and have nothing to do with the format described here. An Xfig file is recognised instantly by its first line: the literal string #FIG followed by a version number, such as #FIG 3.2. The current format version is 3.2; the text below describes it.

The #FIG header lines

A 3.2 file begins with a fixed header before any drawing objects appear. The first line is the version marker. It is followed by header fields, one value per line, in a defined order:

#FIG 3.2  Produced by xfig version 3.2.8
Landscape          # orientation: Landscape or Portrait
Center             # justification: Center or Flush Left
Metric             # units: Metric or Inches
A4                 # papersize: A4, Letter, Legal, Ledger, A0-A5, B5 ...
100.00             # export/print magnification, in percent
Single             # Single or Multiple page
-2                 # transparent colour: -2 = None, -1 = default, 0-31 std, 32+ user
1200 2             # resolution (Fig units per inch) and coord_system (2 = upper-left)

Two of these fields matter most for interpreting coordinates. The resolution gives how many Fig units make one inch; the near-universal value is 1200, so a coordinate of 1200 is one inch from the origin. The coord_system value 2 means the origin is the upper-left corner with y increasing downward (the value 1, lower-left, is not used by modern Xfig). The transparent color field on the header’s seventh line uses the special codes -2 for none and -1 for the default, with 031 naming the standard palette and 32 upward naming user-defined colours. Any line whose first character is # is a comment and is ignored by parsers.

Object records and their type codes

After the header, the body of the file is a flat list of objects. Each object record starts with an integer object code that tells the parser what kind of shape follows and therefore how to read the rest of the record. The 3.2 format defines seven codes:

CodeObjectWhat it draws
0Colour pseudo-objectDefines a user colour (RGB) for later objects
1EllipseCircle or ellipse, by radii or diameters
2PolylineLine, polygon, box, arc-box, or imported picture
3SplineOpen/closed interpolated or approximated spline
4TextA text string with font, size and angle
5ArcA circular arc through three points
6CompoundGroups the following objects; ends with -6

The colour pseudo-object (code 0) is special: it defines nothing visible, only a palette entry, and Xfig requires that all colour definitions come before any drawing object that references them. The compound object (code 6) is a grouping bracket — it opens a group, the grouped objects follow, and a line containing just -6 closes it — which is how Xfig nests parts of a drawing.

A polyline record, field by field

The polyline (code 2) is the workhorse and shows how a record encodes its attributes. Its first line packs the drawing properties, and one or more following lines hold the vertex coordinates. A typical polyline first line looks like this:

2 1 0 2 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
    600 600 2400 600 2400 1800 600 1800 600 600

Reading the first line left to right: 2 is the object code; the next value is the sub_type (1 = polyline, 2 = box, 3 = polygon, 4 = arc-box, 5 = imported picture). Then come line_style (0 = solid, 1 = dashed, 2 = dotted), thickness in 1/80 inch, pen_color and fill_color (palette indices), depth (0–999, controlling draw order — lower depth is on top), pen_style, area_fill, the dash-gap style_val, then join_style (0 Miter, 1 Round, 2 Bevel) and cap_style (0 Butt, 1 Round, 2 Projecting), the arc-box radius, forward/backward arrow flags, and finally the number of points. The second line lists that many x y coordinate pairs in Fig units. The example draws a closed rectangle from (600,600), five points because the last vertex repeats the first to close the shape.

Every object type follows the same principle: a fixed set of attribute fields (many shared across types — line style, thickness, colours, depth, fill), then the geometry. Because the attributes are positional integers, the format is compact and unambiguous, but it is also strict: a missing or extra field on a line breaks the record.

Depth ordering, colours and fill

Xfig has no z-coordinate; instead every object carries a depth from 0 to 999. Objects with a smaller depth are drawn later and therefore appear on top, so depth acts as an explicit layer number. This lets a drawing control occlusion precisely without reordering the file: two overlapping shapes at depths 40 and 50 always render with the depth-40 object in front.

Colour is an index, not an inline RGB value. The 32 standard colours occupy indices 0–31 (0 = black, 1 = blue, and so on), and anything beyond needs a colour pseudo-object at the top of the file that maps an index ≥ 32 to a hex RGB triple. The area_fill field selects how a closed shape is filled: a value of -1 means no fill, values in one range give solid tints from the fill colour toward black or white, and another range selects hatch/pattern fills. Because fill and pen colours are separate indices, a shape can be outlined in one palette colour and filled with a shade of another.

fig2dev: turning a .fig into SVG, PDF or EPS

Xfig itself edits the drawing, but exporting to a portable format is the job of a companion program, fig2dev (distributed as part of Transfig). fig2dev reads the .fig text and drives one of many output back-ends: PostScript and EPS, PDF, SVG, PNG and other bitmaps, plus LaTeX-oriented outputs like PSTricks and PGF that let a figure integrate with typeset text. On Windows the WinFIG editor reads and writes the same 3.2 format, and jfig provides a Java implementation, so the plain-text format travels across platforms even though the original Xfig program is X11-only.

Because the format is fully documented and text-based, it is also easy to generate programmatically: scripts that emit charts or diagrams can write .fig directly and hand it to fig2dev, which is one reason the format persisted in academic and engineering toolchains long after WYSIWYG editors became common.

FAQ

How do I open an Xfig .fig file?

Edit it in Xfig on Linux/Unix (or WinFIG on Windows, jfig on any Java system). To simply read it, open it in a text editor — it is ASCII. To view it as a picture, convert it with fig2dev to SVG, PDF or PNG.

My .fig won’t open in a text editor — is it still Xfig?

Probably not. If the file is binary rather than starting with #FIG, it is a different format that reuses the extension — most likely a Figma design file or a MATLAB figure, both of which are binary and open only in their own applications.

References