wolffd@0:
wolffd@0: wolffd@0: The formats actually available in a given Graphviz system depend on wolffd@0: how the system was built and the presence of additional libraries. wolffd@0: To see what formats dot supports, run dot -T?. wolffd@0: See the description of the -T wolffd@0: flag for additional information. wolffd@0:
wolffd@0: Note that the internal coordinate system has the origin wolffd@0: in the lower left corner. wolffd@0: Thus, positions in the wolffd@0: canon, wolffd@0: dot, wolffd@0: xdot, wolffd@0: plain, and wolffd@0: plain-ext wolffd@0: formats need to be interpreted in this manner. wolffd@0:
wolffd@0:
| Command-line parameter | Format |
|---|---|
| bmp wolffd@0: | Windows Bitmap Format |
| canon
wolffd@0: dot wolffd@0: xdot wolffd@0: | DOT |
| cmap wolffd@0: | Client-side imagemap (deprecated) |
| dia wolffd@0: | Dia format |
| eps wolffd@0: | Encapsulated PostScript |
| fig wolffd@0: | FIG |
| gd
wolffd@0: gd2 wolffd@0: | GD/GD2 formats |
| gif wolffd@0: | GIF |
| gtk wolffd@0: | GTK canvas |
| hpgl wolffd@0: | HP-GL/2 |
| ico wolffd@0: | Icon Image File Format |
| imap
wolffd@0: cmapx wolffd@0: | Server-side and client-side imagemaps |
| imap_np
wolffd@0: cmapx_np wolffd@0: | Server-side and client-side imagemaps |
| ismap wolffd@0: | Server-side imagemap (deprecated) |
| jpg
wolffd@0: jpeg wolffd@0: jpe wolffd@0: | JPEG |
| mif wolffd@0: | FrameMaker MIF format |
| mp wolffd@0: | MetaPost |
| pcl wolffd@0: | PCL |
| pdf wolffd@0: | Portable Document Format (PDF) |
| pic wolffd@0: | PIC |
| plain
wolffd@0: plain-ext wolffd@0: | Simple text format |
| png wolffd@0: | Portable Network Graphics format |
| ps wolffd@0: | PostScript |
| ps2 wolffd@0: | PostScript for PDF |
| svg
wolffd@0: svgz wolffd@0: | Scalable Vector Graphics |
| tga wolffd@0: | Truevision Targa Format (TGA) |
| tif
wolffd@0: tiff wolffd@0: | TIFF (Tag Image File Format) |
| vml
wolffd@0: vmlz wolffd@0: | Vector Markup Language (VML) |
| vrml wolffd@0: | VRML |
| vtx wolffd@0: | Visual Thought format |
| wbmp wolffd@0: | Wireless BitMap format |
| xlib wolffd@0: | Xlib canvas |
wolffd@0: The dot option corresponds to attributed dot output, wolffd@0: and is the default output format. wolffd@0: It reproduces the input, along with layout information for the graph. wolffd@0: In particular, a bb attribute is wolffd@0: attached to the graph, specifying the bounding box of the drawing. wolffd@0: If the graph has a label, its position is specified by the wolffd@0: lp attribute. wolffd@0:
wolffd@0: Each node gets pos, wolffd@0: width and wolffd@0: height attributes. If the node is a record, wolffd@0: the record rectangles are given in the wolffd@0: rects attribute. wolffd@0: If the node is a polygon and the wolffd@0: vertices attribute is defined, this wolffd@0: attribute contains the vertices of the node. wolffd@0:
wolffd@0: Every edge is wolffd@0: assigned a pos attribute, wolffd@0: and if the edge has a label, the label position wolffd@0: is given in lp. wolffd@0:
wolffd@0: The xdot format extends the wolffd@0: dot format by providing much more detailed information about wolffd@0: how graph components are drawn. It relies on additional attributes wolffd@0: for nodes, edges and graphs. wolffd@0:
wolffd@0: The format is preliminary; comments and wolffd@0: suggestions for better representations are welcome. wolffd@0: To allow for changes in the format, Graphviz attaches the attribute wolffd@0: xdotversion to the graph. wolffd@0:
wolffd@0: Additional drawing attributes can appear on nodes, edges, clusters and
wolffd@0: on the graph itself. There are six new attributes:
wolffd@0:
wolffd@0: For a given graph object, one will typically a draw directive before the
wolffd@0: label directive. For example, for a node, one would first use the commands
wolffd@0: in _draw_ followed by the commands in _ldraw_.
wolffd@0:
wolffd@0: The value of these attributes consists of the concatenation of some
wolffd@0: (multi-)set of the following 13 rendering or attribute operations.
wolffd@0: (The number is parentheses gives the xdot version when the operation
wolffd@0: was added to the format. If no version number is given, the operation
wolffd@0: was in the original specification.)
wolffd@0:
wolffd@0: Note that the filled figures (ellipses, polygons and B-Splines)
wolffd@0: imply two operations: first, drawing the filled figure with the
wolffd@0: current fill color; second, drawing an unfilled figure with the
wolffd@0: current pen color, pen width and pen style.
wolffd@0: the
wolffd@0:
wolffd@0: Style values which can be incorporated in the graphics model do not
wolffd@0: appear in xdot output. In particular, the style values
wolffd@0: filled, rounded, diagonals, and invis
wolffd@0: will not appear. Indeed, if style contains invis,
wolffd@0: there will not be any xdot output at all.
wolffd@0:
wolffd@0: In handling text alignment, the application may want to recompute the
wolffd@0: string width using its own rendering primitives.
wolffd@0:
wolffd@0: The text operation is only used in the label attributes. Normally,
wolffd@0: the non-text operations are only used in the non-label attributes.
wolffd@0: If, however, the decorate
wolffd@0: attribute is set on an edge, its label
wolffd@0: attribute will also contain a polyline operation.
wolffd@0: In addition, if a label is a complex, HTML-like label, it will also
wolffd@0: contain non-text operations.
wolffd@0:
wolffd@0: All coordinates and sizes are in points.
wolffd@0: Note though that if
wolffd@0: an edge or node is invisible, no drawing operations are attached to it.
wolffd@0:
wolffd@0: Version info:
wolffd@0:
wolffd@0: See Note.
wolffd@0:
wolffd@0:
wolffd@0: If the URL
wolffd@0: of a node contains the escape sequence "\N", it will be replaced by
wolffd@0: the node's name.
wolffd@0: If the headURL is defined and contains the escape sequence "\N",
wolffd@0: it will be replaced by
wolffd@0: the headlabel, if defined.
wolffd@0: The analogous result holds for the tailURL and the
wolffd@0: taillabel.
wolffd@0:
wolffd@0: See Note.
wolffd@0:
wolffd@0:
wolffd@0: Note: At present, this option does not support anchors, etc. To get these
wolffd@0: included in your PDF output, use ps2.
wolffd@0:
wolffd@0:
wolffd@0: There are four types of statements.
wolffd@0:
wolffd@0: Note: The control points given in an edge statement define the
wolffd@0: body of the edge. In particular, if the edge has an arrowhead to the
wolffd@0: head or tail node,
wolffd@0: there will be a gap between the last or first control points and the
wolffd@0: boundary of the associated node. There are at least 3 possible ways
wolffd@0: of handling this gap:
wolffd@0:
wolffd@0: Note that the plain formats provide minimal information, really giving not
wolffd@0: much more than node positions and sizes, and edge spline control points.
wolffd@0: These formats are usually most useful to applications wanting just this
wolffd@0: geometric information, and willing to fill in all of the graphical details.
wolffd@0: The only real advantages to these formats is their terseness and their
wolffd@0: ease of parsing. In general, the dot and
wolffd@0: xdot are preferable in terms of the quantity of
wolffd@0: information provided.
wolffd@0:
wolffd@0:
wolffd@0: Note: The default PostScript renderer can only handle the Latin-1
wolffd@0: character set. To get non-Latin-1 characters into PostScript output,
wolffd@0: use -Tps:cairo, assuming your version was built with the
wolffd@0: Cairo renderer.
wolffd@0:
wolffd@0:
wolffd@0: See Note.
wolffd@0:
wolffd@0:
wolffd@0: See Note.
wolffd@0:
wolffd@0:
wolffd@0: Line segments are drawn as cylinders.
wolffd@0: In general, VRML output relies on having the PNG library to produce images
wolffd@0: used to texture-fill the node shapes. However, if
wolffd@0: shape=point,
wolffd@0: a node is drawn as a 3D sphere.
wolffd@0:
wolffd@0:
wolffd@0:
wolffd@0: _draw_ Drawing operations
wolffd@0: _ldraw_ Label drawing
wolffd@0: _hdraw_ Head arrowhead Edge only
wolffd@0: _tdraw_ Tail arrowhead Edge only
wolffd@0: _hldraw_ Head label Edge only
wolffd@0: _tldraw_ Tail label Edge only
wolffd@0:
wolffd@0:
wolffd@0: E x0 y0 w h
wolffd@0: Filled ellipse ((x-x0)/w)2 + ((y-y0)/h)2 = 1
wolffd@0: e x0 y0 w h
wolffd@0: Unfilled ellipse ((x-x0)/w)2 + ((y-y0)/h)2 = 1
wolffd@0: P n x1 y1 ... xn yn
wolffd@0: Filled polygon using the given n points
wolffd@0: p n x1 y1 ... xn yn
wolffd@0: Unfilled polygon using the given n points
wolffd@0: L n x1 y1 ... xn yn
wolffd@0: Polyline using the given n points
wolffd@0: B n x1 y1 ... xn yn
wolffd@0: B-spline using the given n control points
wolffd@0: b n x1 y1 ... xn yn
wolffd@0: Filled B-spline using the given n control points (1.1)
wolffd@0: T x y j w n -b1b2...bn
wolffd@0: Text drawn using the baseline point (x,y). The text consists of the
wolffd@0: n bytes following '-'. The text should be left-aligned (centered,
wolffd@0: right-aligned) on the point if j is -1 (0, 1), respectively. The value
wolffd@0: w gives the width of the text as computed by the library.
wolffd@0: C n -b1b2...bn
wolffd@0: Set fill color. The color value consists of the
wolffd@0: n bytes following '-'. (1.1)
wolffd@0: c n -b1b2...bn
wolffd@0: Set pen color. The color value consists of the
wolffd@0: n bytes following '-'. (1.1)
wolffd@0: F s n -b1b2...bn
wolffd@0: Set font. The font size is s points. The font name consists of the
wolffd@0: n bytes following '-'. (1.1)
wolffd@0: S n -b1b2...bn
wolffd@0: Set style attribute. The style value consists of the
wolffd@0: n bytes following '-'. The syntax of the value is the same as
wolffd@0: specified for a styleItem in style. (1.1)
wolffd@0: I x y w h n -b1b2...bn
wolffd@0: Externally-specified image drawn in the box with lower left
wolffd@0: corner (x,y) and upper right corner (x+w,y+h). The name of the image
wolffd@0: consists of the n bytes following '-'. This is usually a bitmap
wolffd@0: image. Note that the image size, even when converted from pixels to
wolffd@0: points, might be different from the required size (w,h). It is
wolffd@0: assumed the renderer will perform the necessary scaling. (1.2)
wolffd@0:
wolffd@0:
wolffd@0:
wolffd@0: Xdot version Graphviz version 1.0 1.9 1.1 2.8 1.2 2.13
wolffd@0: /* x.dot */
wolffd@0: digraph mainmap {
wolffd@0: URL="http://www.research.att.com/base.html";
wolffd@0: command [URL="http://www.research.att.com/command.html"];
wolffd@0: command -> output [URL="colors.html"];
wolffd@0: }
wolffd@0:
wolffd@0: one would process the graph and generate two output files:
wolffd@0:
wolffd@0: dot -Timap -ox.map -Tgif -ox.gif x.dot
wolffd@0:
wolffd@0: and then refer to it in a web page:
wolffd@0:
wolffd@0: dot -Tcmapx -ox.map -Tgif -ox.gif x.dot
wolffd@0:
wolffd@0: and uses the HTML
wolffd@0:
wolffd@0: graph scale width height
wolffd@0: node name x y width height label style shape color fillcolor
wolffd@0: edge tail head n x1 y1 .. xn yn [label xl yl] style color
wolffd@0: stop
wolffd@0:
wolffd@0:
wolffd@0:
wolffd@0: The output consists of one graph line, a sequence of
wolffd@0: node lines, one per node, a sequence of
wolffd@0: edge lines, one per edge, and a final stop
wolffd@0: line. All units are in inches, represented by a floating point number.
wolffd@0:
wolffd@0:
wolffd@0:
wolffd@0: The graph below shows what image formats can be used in which output formats,
wolffd@0: and the required plugins. On the left are the supported image formats.
wolffd@0: On the right are the supported output formats.
wolffd@0: In the middle are the plugins: image loaders, renderers, drivers, arranged by
wolffd@0: plugin library.
wolffd@0: This presents the most general case. A given installation may not provide
wolffd@0: one of the plugins, in which case, that transformation is not possible.
wolffd@0:
wolffd@0:
wolffd@0: