wolffd@0
|
1 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
|
wolffd@0
|
2 <!--
|
wolffd@0
|
3 This is a generated document. Do not edit.
|
wolffd@0
|
4 -->
|
wolffd@0
|
5 <HTML VERSION="2.0">
|
wolffd@0
|
6 <HEAD>
|
wolffd@0
|
7 <TITLE>Output Formats</TITLE>
|
wolffd@0
|
8 </HEAD>
|
wolffd@0
|
9 <BODY BGCOLOR=white>
|
wolffd@0
|
10 <A NAME="top"></A>
|
wolffd@0
|
11 <H1 align=CENTER>Output Formats</H1>
|
wolffd@0
|
12 <HR>
|
wolffd@0
|
13 The output format is specified with the <STRONG>-T</STRONG><I>lang</I>
|
wolffd@0
|
14 flag on the <A HREF=command.html>command line</A>, where <I>lang</I>
|
wolffd@0
|
15 is one of the parameters listed below.
|
wolffd@0
|
16 <P>
|
wolffd@0
|
17 The formats actually available in a given Graphviz system depend on
|
wolffd@0
|
18 how the system was built and the presence of additional libraries.
|
wolffd@0
|
19 To see what formats <b>dot</b> supports, run <TT>dot -T?</TT>.
|
wolffd@0
|
20 See the <A HREF=command.html#d.T> description of the -T</A>
|
wolffd@0
|
21 flag for additional information.
|
wolffd@0
|
22 <P>
|
wolffd@0
|
23 Note that the internal coordinate system has the origin
|
wolffd@0
|
24 in the lower left corner.
|
wolffd@0
|
25 Thus, positions in the
|
wolffd@0
|
26 <A HREF=#d:canon>canon</A>,
|
wolffd@0
|
27 <A HREF=#d:dot>dot</A>,
|
wolffd@0
|
28 <A HREF=#d:xdot>xdot</A>,
|
wolffd@0
|
29 <A HREF=#d:plain>plain</A>, and
|
wolffd@0
|
30 <A HREF=#d:plain-ext>plain-ext</A>
|
wolffd@0
|
31 formats need to be interpreted in this manner.
|
wolffd@0
|
32 <P>
|
wolffd@0
|
33 <TABLE ALIGN=CENTER>
|
wolffd@0
|
34 <TR><TH>Command-line<BR>parameter</TH><TH>Format</TH></TR>
|
wolffd@0
|
35 <TR><TD ALIGN=CENTER><A NAME=a:bmp HREF=#d:bmp>bmp</A>
|
wolffd@0
|
36 </TD><TD>Windows Bitmap Format</TD> </TR>
|
wolffd@0
|
37 <TR><TD ALIGN=CENTER><A NAME=a:canon HREF=#d:canon>canon</A>
|
wolffd@0
|
38 <BR><A NAME=a:dot HREF=#d:dot>dot</A>
|
wolffd@0
|
39 <BR><A NAME=a:xdot HREF=#d:xdot>xdot</A>
|
wolffd@0
|
40 </TD><TD>DOT</TD> </TR>
|
wolffd@0
|
41 <TR><TD ALIGN=CENTER><A NAME=a:cmap HREF=#d:cmap>cmap</A>
|
wolffd@0
|
42 </TD><TD>Client-side imagemap (deprecated)</TD> </TR>
|
wolffd@0
|
43 <TR><TD ALIGN=CENTER><A NAME=a:dia HREF=#d:dia>dia</A>
|
wolffd@0
|
44 </TD><TD>Dia format</TD> </TR>
|
wolffd@0
|
45 <TR><TD ALIGN=CENTER><A NAME=a:eps HREF=#d:eps>eps</A>
|
wolffd@0
|
46 </TD><TD>Encapsulated PostScript</TD> </TR>
|
wolffd@0
|
47 <TR><TD ALIGN=CENTER><A NAME=a:fig HREF=#d:fig>fig</A>
|
wolffd@0
|
48 </TD><TD>FIG</TD> </TR>
|
wolffd@0
|
49 <TR><TD ALIGN=CENTER><A NAME=a:gd HREF=#d:gd>gd</A>
|
wolffd@0
|
50 <BR><A NAME=a:gd2 HREF=#d:gd2>gd2</A>
|
wolffd@0
|
51 </TD><TD>GD/GD2 formats</TD> </TR>
|
wolffd@0
|
52 <TR><TD ALIGN=CENTER><A NAME=a:gif HREF=#d:gif>gif</A>
|
wolffd@0
|
53 </TD><TD>GIF</TD> </TR>
|
wolffd@0
|
54 <TR><TD ALIGN=CENTER><A NAME=a:gtk HREF=#d:gtk>gtk</A>
|
wolffd@0
|
55 </TD><TD>GTK canvas</TD> </TR>
|
wolffd@0
|
56 <TR><TD ALIGN=CENTER><A NAME=a:hpgl HREF=#d:hpgl>hpgl</A>
|
wolffd@0
|
57 </TD><TD>HP-GL/2</TD> </TR>
|
wolffd@0
|
58 <TR><TD ALIGN=CENTER><A NAME=a:ico HREF=#d:ico>ico</A>
|
wolffd@0
|
59 </TD><TD>Icon Image File Format</TD> </TR>
|
wolffd@0
|
60 <TR><TD ALIGN=CENTER><A NAME=a:imap HREF=#d:imap>imap</A>
|
wolffd@0
|
61 <BR><A NAME=a:cmapx HREF=#d:cmapx>cmapx</A>
|
wolffd@0
|
62 </TD><TD>Server-side and client-side imagemaps</TD> </TR>
|
wolffd@0
|
63 <TR><TD ALIGN=CENTER><A NAME=a:imap_np HREF=#d:imap_np>imap_np</A>
|
wolffd@0
|
64 <BR><A NAME=a:cmapx_np HREF=#d:cmapx_np>cmapx_np</A>
|
wolffd@0
|
65 </TD><TD>Server-side and client-side imagemaps</TD> </TR>
|
wolffd@0
|
66 <TR><TD ALIGN=CENTER><A NAME=a:ismap HREF=#d:ismap>ismap</A>
|
wolffd@0
|
67 </TD><TD>Server-side imagemap (deprecated)</TD> </TR>
|
wolffd@0
|
68 <TR><TD ALIGN=CENTER><A NAME=a:jpg HREF=#d:jpg>jpg</A>
|
wolffd@0
|
69 <BR><A NAME=a:jpeg HREF=#d:jpeg>jpeg</A>
|
wolffd@0
|
70 <BR><A NAME=a:jpe HREF=#d:jpe>jpe</A>
|
wolffd@0
|
71 </TD><TD>JPEG</TD> </TR>
|
wolffd@0
|
72 <TR><TD ALIGN=CENTER><A NAME=a:mif HREF=#d:mif>mif</A>
|
wolffd@0
|
73 </TD><TD>FrameMaker MIF format</TD> </TR>
|
wolffd@0
|
74 <TR><TD ALIGN=CENTER><A NAME=a:mp HREF=#d:mp>mp</A>
|
wolffd@0
|
75 </TD><TD>MetaPost</TD> </TR>
|
wolffd@0
|
76 <TR><TD ALIGN=CENTER><A NAME=a:pcl HREF=#d:pcl>pcl</A>
|
wolffd@0
|
77 </TD><TD>PCL</TD> </TR>
|
wolffd@0
|
78 <TR><TD ALIGN=CENTER><A NAME=a:pdf HREF=#d:pdf>pdf</A>
|
wolffd@0
|
79 </TD><TD>Portable Document Format (PDF)</TD> </TR>
|
wolffd@0
|
80 <TR><TD ALIGN=CENTER><A NAME=a:pic HREF=#d:pic>pic</A>
|
wolffd@0
|
81 </TD><TD>PIC</TD> </TR>
|
wolffd@0
|
82 <TR><TD ALIGN=CENTER><A NAME=a:plain HREF=#d:plain>plain</A>
|
wolffd@0
|
83 <BR><A NAME=a:plain-ext HREF=#d:plain-ext>plain-ext</A>
|
wolffd@0
|
84 </TD><TD>Simple text format</TD> </TR>
|
wolffd@0
|
85 <TR><TD ALIGN=CENTER><A NAME=a:png HREF=#d:png>png</A>
|
wolffd@0
|
86 </TD><TD>Portable Network Graphics format</TD> </TR>
|
wolffd@0
|
87 <TR><TD ALIGN=CENTER><A NAME=a:ps HREF=#d:ps>ps</A>
|
wolffd@0
|
88 </TD><TD>PostScript</TD> </TR>
|
wolffd@0
|
89 <TR><TD ALIGN=CENTER><A NAME=a:ps2 HREF=#d:ps2>ps2</A>
|
wolffd@0
|
90 </TD><TD>PostScript for PDF</TD> </TR>
|
wolffd@0
|
91 <TR><TD ALIGN=CENTER><A NAME=a:svg HREF=#d:svg>svg</A>
|
wolffd@0
|
92 <BR><A NAME=a:svgz HREF=#d:svgz>svgz</A>
|
wolffd@0
|
93 </TD><TD>Scalable Vector Graphics</TD> </TR>
|
wolffd@0
|
94 <TR><TD ALIGN=CENTER><A NAME=a:tga HREF=#d:tga>tga</A>
|
wolffd@0
|
95 </TD><TD>Truevision Targa Format (TGA)</TD> </TR>
|
wolffd@0
|
96 <TR><TD ALIGN=CENTER><A NAME=a:tif HREF=#d:tif>tif</A>
|
wolffd@0
|
97 <BR><A NAME=a:tiff HREF=#d:tiff>tiff</A>
|
wolffd@0
|
98 </TD><TD>TIFF (Tag Image File Format)</TD> </TR>
|
wolffd@0
|
99 <TR><TD ALIGN=CENTER><A NAME=a:vml HREF=#d:vml>vml</A>
|
wolffd@0
|
100 <BR><A NAME=a:vmlz HREF=#d:vmlz>vmlz</A>
|
wolffd@0
|
101 </TD><TD>Vector Markup Language (VML)</TD> </TR>
|
wolffd@0
|
102 <TR><TD ALIGN=CENTER><A NAME=a:vrml HREF=#d:vrml>vrml</A>
|
wolffd@0
|
103 </TD><TD>VRML</TD> </TR>
|
wolffd@0
|
104 <TR><TD ALIGN=CENTER><A NAME=a:vtx HREF=#d:vtx>vtx</A>
|
wolffd@0
|
105 </TD><TD>Visual Thought format</TD> </TR>
|
wolffd@0
|
106 <TR><TD ALIGN=CENTER><A NAME=a:wbmp HREF=#d:wbmp>wbmp</A>
|
wolffd@0
|
107 </TD><TD>Wireless BitMap format</TD> </TR>
|
wolffd@0
|
108 <TR><TD ALIGN=CENTER><A NAME=a:xlib HREF=#d:xlib>xlib</A>
|
wolffd@0
|
109 </TD><TD>Xlib canvas</TD> </TR>
|
wolffd@0
|
110 </TABLE>
|
wolffd@0
|
111 <HR>
|
wolffd@0
|
112 <H2>Format Descriptions</H2>
|
wolffd@0
|
113 <DL>
|
wolffd@0
|
114 <DT><A NAME=d:bmp HREF=#a:bmp><STRONG>bmp</STRONG></A>
|
wolffd@0
|
115 <DD>Outputs images in the Windows <A HREF="http://en.wikipedia.org/wiki/Bitmap">BMP</A> format.
|
wolffd@0
|
116
|
wolffd@0
|
117 <DT><A NAME=d:canon HREF=#a:canon><STRONG>canon</STRONG></A>
|
wolffd@0
|
118 ,<DT><A NAME=d:dot HREF=#a:dot><STRONG>dot</STRONG></A>
|
wolffd@0
|
119 ,<DT><A NAME=d:xdot HREF=#a:xdot><STRONG>xdot</STRONG></A>
|
wolffd@0
|
120 <DD>These formats produce output in the
|
wolffd@0
|
121 <A HREF=lang.html>dot language</A>.
|
wolffd@0
|
122 Using <B>canon</B> produces a prettyprinted version of the input,
|
wolffd@0
|
123 with no layout performed.
|
wolffd@0
|
124 <P>
|
wolffd@0
|
125 The <B>dot</B> option corresponds to attributed dot output,
|
wolffd@0
|
126 and is the default output format.
|
wolffd@0
|
127 It reproduces the input, along with layout information for the graph.
|
wolffd@0
|
128 In particular, a <A HREF=attrs.html#d:bb>bb</A> attribute is
|
wolffd@0
|
129 attached to the graph, specifying the bounding box of the drawing.
|
wolffd@0
|
130 If the graph has a label, its position is specified by the
|
wolffd@0
|
131 <A HREF=attrs.html#d:lp>lp</A> attribute.
|
wolffd@0
|
132 <P>
|
wolffd@0
|
133 Each node gets <A HREF=attrs.html#d:pos>pos</A>,
|
wolffd@0
|
134 <A HREF=attrs.html#d:width>width</A> and
|
wolffd@0
|
135 <A HREF=attrs.html#d:height>height</A> attributes. If the node is a record,
|
wolffd@0
|
136 the record rectangles are given in the
|
wolffd@0
|
137 <A HREF=attrs.html#d:rects>rects</A> attribute.
|
wolffd@0
|
138 If the node is a polygon and the
|
wolffd@0
|
139 <A HREF=attrs.html#d:vertices>vertices</A> attribute is defined, this
|
wolffd@0
|
140 attribute contains the vertices of the node.
|
wolffd@0
|
141 <P>
|
wolffd@0
|
142 Every edge is
|
wolffd@0
|
143 assigned a <A HREF=attrs.html#d:pos>pos</A> attribute,
|
wolffd@0
|
144 and if the edge has a label, the label position
|
wolffd@0
|
145 is given in <A HREF=attrs.html#d:lp>lp</A>.
|
wolffd@0
|
146 <P>
|
wolffd@0
|
147 The <B>xdot</B> format extends the
|
wolffd@0
|
148 <B>dot</B> format by providing much more detailed information about
|
wolffd@0
|
149 how graph components are drawn. It relies on additional attributes
|
wolffd@0
|
150 for nodes, edges and graphs.
|
wolffd@0
|
151 <P>
|
wolffd@0
|
152 The format is preliminary; comments and
|
wolffd@0
|
153 suggestions for better representations are welcome.
|
wolffd@0
|
154 To allow for changes in the format, Graphviz attaches the attribute
|
wolffd@0
|
155 <TT>xdotversion</TT> to the graph.
|
wolffd@0
|
156 <P>
|
wolffd@0
|
157 Additional drawing attributes can appear on nodes, edges, clusters and
|
wolffd@0
|
158 on the graph itself. There are six new attributes:
|
wolffd@0
|
159 <SPACER TYPE=VERTICAL size=10>
|
wolffd@0
|
160 <TABLE border bgcolor=beige>
|
wolffd@0
|
161 <TR><TD>_draw_<TD colspan=2>Drawing operations
|
wolffd@0
|
162 <TR><TD>_ldraw_<TD colspan=2>Label drawing
|
wolffd@0
|
163 <TR><TD>_hdraw_<TD>Head arrowhead<TD>Edge only
|
wolffd@0
|
164 <TR><TD>_tdraw_<TD>Tail arrowhead<TD>Edge only
|
wolffd@0
|
165 <TR><TD>_hldraw_<TD>Head label<TD>Edge only
|
wolffd@0
|
166 <TR><TD>_tldraw_<TD>Tail label<TD>Edge only
|
wolffd@0
|
167 </TABLE>
|
wolffd@0
|
168 <P>
|
wolffd@0
|
169 For a given graph object, one will typically a draw directive before the
|
wolffd@0
|
170 label directive. For example, for a node, one would first use the commands
|
wolffd@0
|
171 in <B>_draw_</B> followed by the commands in <B>_ldraw_</B>.
|
wolffd@0
|
172 <P>
|
wolffd@0
|
173 The value of these attributes consists of the concatenation of some
|
wolffd@0
|
174 (multi-)set of the following 13 rendering or attribute operations.
|
wolffd@0
|
175 (The number is parentheses gives the xdot version when the operation
|
wolffd@0
|
176 was added to the format. If no version number is given, the operation
|
wolffd@0
|
177 was in the original specification.)
|
wolffd@0
|
178 <SPACER TYPE=VERTICAL size=10>
|
wolffd@0
|
179 <TABLE border bgcolor=beige>
|
wolffd@0
|
180 <TR><TD>E x<sub>0</sub> y<sub>0</sub> w h
|
wolffd@0
|
181 <TD>Filled ellipse ((x-x<sub>0</sub>)/w)<sup>2</sup> + ((y-y<sub>0</sub>)/h)<sup>2</sup> = 1
|
wolffd@0
|
182 <TR><TD>e x<sub>0</sub> y<sub>0</sub> w h
|
wolffd@0
|
183 <TD>Unfilled ellipse ((x-x<sub>0</sub>)/w)<sup>2</sup> + ((y-y<sub>0</sub>)/h)<sup>2</sup> = 1
|
wolffd@0
|
184 <TR><TD>P n x<sub>1</sub> y<sub>1</sub> ... x<sub>n</sub> y<sub>n</sub>
|
wolffd@0
|
185 <TD>Filled polygon using the given n points
|
wolffd@0
|
186 <TR><TD>p n x<sub>1</sub> y<sub>1</sub> ... x<sub>n</sub> y<sub>n</sub>
|
wolffd@0
|
187 <TD>Unfilled polygon using the given n points
|
wolffd@0
|
188 <TR><TD>L n x<sub>1</sub> y<sub>1</sub> ... x<sub>n</sub> y<sub>n</sub>
|
wolffd@0
|
189 <TD>Polyline using the given n points
|
wolffd@0
|
190 <TR><TD>B n x<sub>1</sub> y<sub>1</sub> ... x<sub>n</sub> y<sub>n</sub>
|
wolffd@0
|
191 <TD>B-spline using the given n control points
|
wolffd@0
|
192 <TR><TD>b n x<sub>1</sub> y<sub>1</sub> ... x<sub>n</sub> y<sub>n</sub>
|
wolffd@0
|
193 <TD>Filled B-spline using the given n control points (1.1)
|
wolffd@0
|
194 <TR><TD>T x y j w n -<I>b<sub>1</sub>b<sub>2</sub>...b<sub>n</sub></I>
|
wolffd@0
|
195 <TD>Text drawn using the baseline point (x,y). The text consists of the
|
wolffd@0
|
196 n bytes following '-'. The text should be left-aligned (centered,
|
wolffd@0
|
197 right-aligned) on the point if j is -1 (0, 1), respectively. The value
|
wolffd@0
|
198 w gives the width of the text as computed by the library.
|
wolffd@0
|
199 <TR><TD>C n -<I>b<sub>1</sub>b<sub>2</sub>...b<sub>n</sub></I>
|
wolffd@0
|
200 <TD>Set fill color. The color value consists of the
|
wolffd@0
|
201 n bytes following '-'. (1.1)
|
wolffd@0
|
202 <TR><TD>c n -<I>b<sub>1</sub>b<sub>2</sub>...b<sub>n</sub></I>
|
wolffd@0
|
203 <TD>Set pen color. The color value consists of the
|
wolffd@0
|
204 n bytes following '-'. (1.1)
|
wolffd@0
|
205 <TR><TD>F s n -<I>b<sub>1</sub>b<sub>2</sub>...b<sub>n</sub></I>
|
wolffd@0
|
206 <TD>Set font. The font size is s points. The font name consists of the
|
wolffd@0
|
207 n bytes following '-'. (1.1)
|
wolffd@0
|
208 <TR><TD>S n -<I>b<sub>1</sub>b<sub>2</sub>...b<sub>n</sub></I>
|
wolffd@0
|
209 <TD>Set style attribute. The style value consists of the
|
wolffd@0
|
210 n bytes following '-'. The syntax of the value is the same as
|
wolffd@0
|
211 specified for a <B>styleItem</B> in <A HREF=attrs.html#k:style>style</A>. (1.1)
|
wolffd@0
|
212 <TR><TD>I x y w h n -<I>b<sub>1</sub>b<sub>2</sub>...b<sub>n</sub></I>
|
wolffd@0
|
213 <TD>Externally-specified image drawn in the box with lower left
|
wolffd@0
|
214 corner (x,y) and upper right corner (x+w,y+h). The name of the image
|
wolffd@0
|
215 consists of the n bytes following '-'. This is usually a bitmap
|
wolffd@0
|
216 image. Note that the image size, even when converted from pixels to
|
wolffd@0
|
217 points, might be different from the required size (w,h). It is
|
wolffd@0
|
218 assumed the renderer will perform the necessary scaling. (1.2)
|
wolffd@0
|
219 </TABLE>
|
wolffd@0
|
220 <P>
|
wolffd@0
|
221 Note that the filled figures (ellipses, polygons and B-Splines)
|
wolffd@0
|
222 imply two operations: first, drawing the filled figure with the
|
wolffd@0
|
223 current fill color; second, drawing an unfilled figure with the
|
wolffd@0
|
224 current pen color, pen width and pen style.
|
wolffd@0
|
225 the
|
wolffd@0
|
226 <P>
|
wolffd@0
|
227 Style values which can be incorporated in the graphics model do not
|
wolffd@0
|
228 appear in xdot output. In particular, the style values
|
wolffd@0
|
229 <TT>filled</TT>, <TT>rounded</TT>, <TT>diagonals</TT>, and <TT>invis</TT>
|
wolffd@0
|
230 will not appear. Indeed, if style contains <TT>invis</TT>,
|
wolffd@0
|
231 there will not be any xdot output at all.
|
wolffd@0
|
232 <P>
|
wolffd@0
|
233 In handling text alignment, the application may want to recompute the
|
wolffd@0
|
234 string width using its own rendering primitives.
|
wolffd@0
|
235 <P>
|
wolffd@0
|
236 The text operation is only used in the label attributes. Normally,
|
wolffd@0
|
237 the non-text operations are only used in the non-label attributes.
|
wolffd@0
|
238 If, however, the <A HREF=attrs.html#d:decorate>decorate</A>
|
wolffd@0
|
239 attribute is set on an edge, its label
|
wolffd@0
|
240 attribute will also contain a polyline operation.
|
wolffd@0
|
241 In addition, if a label is a complex, HTML-like label, it will also
|
wolffd@0
|
242 contain non-text operations.
|
wolffd@0
|
243 <P>
|
wolffd@0
|
244 All coordinates and sizes are in points.
|
wolffd@0
|
245 Note though that if
|
wolffd@0
|
246 an edge or node is invisible, no drawing operations are attached to it.
|
wolffd@0
|
247 <P>
|
wolffd@0
|
248 Version info:
|
wolffd@0
|
249 <TABLE border >
|
wolffd@0
|
250 <TR><TH>Xdot version</TH><TH>Graphviz version</TH></TR>
|
wolffd@0
|
251 <TR><TD>1.0</TD><TD>1.9</TD></TR>
|
wolffd@0
|
252 <TR><TD>1.1</TD><TD>2.8</TD></TR>
|
wolffd@0
|
253 <TR><TD>1.2</TD><TD>2.13</TD></TR>
|
wolffd@0
|
254 </TABLE>
|
wolffd@0
|
255
|
wolffd@0
|
256 <DT><A NAME=d:cmap HREF=#a:cmap><STRONG>cmap</STRONG></A>
|
wolffd@0
|
257 <DD>Produces map files for client-side image maps. The cmap format is
|
wolffd@0
|
258 mostly identical to cmapx, but the latter is well-formed XML amenable
|
wolffd@0
|
259 to processing by XML tools. In particular, the cmapx output is wrapped in
|
wolffd@0
|
260 <map></map>.
|
wolffd@0
|
261 <P>
|
wolffd@0
|
262 See <A HREF=#ID>Note</A>.
|
wolffd@0
|
263
|
wolffd@0
|
264 <DT><A NAME=d:dia HREF=#a:dia><STRONG>dia</STRONG></A>
|
wolffd@0
|
265 <DD>Produces <A HREF="http://www.gnome.org/projects/dia/">Dia</A> output.
|
wolffd@0
|
266
|
wolffd@0
|
267 <DT><A NAME=d:eps HREF=#a:eps><STRONG>eps</STRONG></A>
|
wolffd@0
|
268 <DD>Produces Encapsulated PostScript output.
|
wolffd@0
|
269 At present, this is only guaranteed to be correct for a single
|
wolffd@0
|
270 input graph since the Bounding Box information has to appear
|
wolffd@0
|
271 at the beginning of the output, and this will be based on the first graph.
|
wolffd@0
|
272
|
wolffd@0
|
273 <DT><A NAME=d:fig HREF=#a:fig><STRONG>fig</STRONG></A>
|
wolffd@0
|
274 <DD>Outputs graphs in the FIG graphics language.
|
wolffd@0
|
275
|
wolffd@0
|
276 <DT><A NAME=d:gd HREF=#a:gd><STRONG>gd</STRONG></A>
|
wolffd@0
|
277 ,<DT><A NAME=d:gd2 HREF=#a:gd2><STRONG>gd2</STRONG></A>
|
wolffd@0
|
278 <DD>Output images in the GD and GD2 format. These are the internal
|
wolffd@0
|
279 formats used by the gd library. The latter is compressed.
|
wolffd@0
|
280
|
wolffd@0
|
281 <DT><A NAME=d:gif HREF=#a:gif><STRONG>gif</STRONG></A>
|
wolffd@0
|
282 <DD>Outputs GIF bitmap images.
|
wolffd@0
|
283
|
wolffd@0
|
284 <DT><A NAME=d:gtk HREF=#a:gtk><STRONG>gtk</STRONG></A>
|
wolffd@0
|
285 <DD>Creates a <A HREF="http://www.gtk.org/">GTK</A> window and displays the output there.
|
wolffd@0
|
286
|
wolffd@0
|
287 <DT><A NAME=d:hpgl HREF=#a:hpgl><STRONG>hpgl</STRONG></A>
|
wolffd@0
|
288 <DD>Produces output in the HP-GL/2 vector graphic printer language.
|
wolffd@0
|
289
|
wolffd@0
|
290 <DT><A NAME=d:ico HREF=#a:ico><STRONG>ico</STRONG></A>
|
wolffd@0
|
291 <DD>Outputs images in the Windows <A HREF="http://en.wikipedia.org/wiki/ICO_(icon_image_file_format)">ICO format</A>.
|
wolffd@0
|
292
|
wolffd@0
|
293 <DT><A NAME=d:imap HREF=#a:imap><STRONG>imap</STRONG></A>
|
wolffd@0
|
294 ,<DT><A NAME=d:cmapx HREF=#a:cmapx><STRONG>cmapx</STRONG></A>
|
wolffd@0
|
295 <DD>Produces map files for server-side and client-side image maps,
|
wolffd@0
|
296 These can be used in a web page with
|
wolffd@0
|
297 a graphical form of the output, e.g. in JPEG or GIF format, to attach
|
wolffd@0
|
298 links to nodes and edges. For example, to create a server-side map
|
wolffd@0
|
299 given the dot file
|
wolffd@0
|
300 <PRE>
|
wolffd@0
|
301 /* x.dot */
|
wolffd@0
|
302 digraph mainmap {
|
wolffd@0
|
303 URL="http://www.research.att.com/base.html";
|
wolffd@0
|
304 command [URL="http://www.research.att.com/command.html"];
|
wolffd@0
|
305 command -> output [URL="colors.html"];
|
wolffd@0
|
306 }
|
wolffd@0
|
307 </PRE>
|
wolffd@0
|
308 one would process the graph and generate two output files:
|
wolffd@0
|
309 <PRE>
|
wolffd@0
|
310 dot -Timap -ox.map -Tgif -ox.gif x.dot
|
wolffd@0
|
311 </PRE>
|
wolffd@0
|
312 and then refer to it in a web page:
|
wolffd@0
|
313 <XMP>
|
wolffd@0
|
314 <A HREF="x.map"><IMG SRC="x.gif" ismap="ismap" /></A>
|
wolffd@0
|
315 </XMP>
|
wolffd@0
|
316 For client-side maps, one again generates two output files:
|
wolffd@0
|
317 <PRE>
|
wolffd@0
|
318 dot -Tcmapx -ox.map -Tgif -ox.gif x.dot
|
wolffd@0
|
319 </PRE>
|
wolffd@0
|
320 and uses the HTML
|
wolffd@0
|
321 <XMP>
|
wolffd@0
|
322 <IMG SRC="x.gif" USEMAP="#mainmap" />
|
wolffd@0
|
323 ... [content of x.map] ...
|
wolffd@0
|
324 </XMP>
|
wolffd@0
|
325 <A HREF=attrs.html#d:URL>URLs</A> can be attached to the root
|
wolffd@0
|
326 graph, nodes and edges. If a node has a URL, clicking in the node
|
wolffd@0
|
327 will activate the link.
|
wolffd@0
|
328 If an edge has a URL, various
|
wolffd@0
|
329 points along the edge (but not necessarily the head or tail)
|
wolffd@0
|
330 will link to it. In addition, if the edge has a
|
wolffd@0
|
331 <A HREF=attrs.html#d:label>label</A>, that will link
|
wolffd@0
|
332 to the URL.
|
wolffd@0
|
333 As for the head of the edge, this is linked to the
|
wolffd@0
|
334 <A HREF=attrs.html#d:headURL>headURL</A>, if set.
|
wolffd@0
|
335 Otherwise, it is linked to the edge's URL if that is defined.
|
wolffd@0
|
336 The analogous description holds for the tail and the
|
wolffd@0
|
337 <A HREF=attrs.html#d:tailURL>tailURL</A>.
|
wolffd@0
|
338 A URL associated with the graph is used as a default link.
|
wolffd@0
|
339 <P>
|
wolffd@0
|
340 If the URL
|
wolffd@0
|
341 of a node contains the escape sequence "\N", it will be replaced by
|
wolffd@0
|
342 the node's name.
|
wolffd@0
|
343 If the headURL is defined and contains the escape sequence "\N",
|
wolffd@0
|
344 it will be replaced by
|
wolffd@0
|
345 the <A HREF=attrs.html#d:headlabel>headlabel</A>, if defined.
|
wolffd@0
|
346 The analogous result holds for the tailURL and the
|
wolffd@0
|
347 <A HREF=attrs.html#d:taillabel>taillabel</A>.
|
wolffd@0
|
348 <P>
|
wolffd@0
|
349 See <A HREF=#ID>Note</A>.
|
wolffd@0
|
350
|
wolffd@0
|
351 <DT><A NAME=d:imap_np HREF=#a:imap_np><STRONG>imap_np</STRONG></A>
|
wolffd@0
|
352 ,<DT><A NAME=d:cmapx_np HREF=#a:cmapx_np><STRONG>cmapx_np</STRONG></A>
|
wolffd@0
|
353 <DD>These are identical to the imap and cmapx formats, except they
|
wolffd@0
|
354 rely solely on rectangles as active areas.
|
wolffd@0
|
355
|
wolffd@0
|
356 <DT><A NAME=d:ismap HREF=#a:ismap><STRONG>ismap</STRONG></A>
|
wolffd@0
|
357 <DD>Produces HTML image map files. This is a predecessor (circa 1994)
|
wolffd@0
|
358 of the IMAP format. Most servers now use the latter.
|
wolffd@0
|
359 <A HREF=attrs.html#d:URL>URLs</A> can be attached to the root graph,
|
wolffd@0
|
360 nodes and edges. Since edge
|
wolffd@0
|
361 links are attached to edge labels, an edge must
|
wolffd@0
|
362 have a <A HREF=attrs.html#d:label>label</A> for its
|
wolffd@0
|
363 URL to be used. For both nodes and edges, if the URL has the escape
|
wolffd@0
|
364 sequence "\N" embedded in its string, this will be replaced with the
|
wolffd@0
|
365 node or edge name.
|
wolffd@0
|
366
|
wolffd@0
|
367 <DT><A NAME=d:jpg HREF=#a:jpg><STRONG>jpg</STRONG></A>
|
wolffd@0
|
368 ,<DT><A NAME=d:jpeg HREF=#a:jpeg><STRONG>jpeg</STRONG></A>
|
wolffd@0
|
369 ,<DT><A NAME=d:jpe HREF=#a:jpe><STRONG>jpe</STRONG></A>
|
wolffd@0
|
370 <DD>Output JPEG compressed image files.
|
wolffd@0
|
371
|
wolffd@0
|
372 <DT><A NAME=d:mif HREF=#a:mif><STRONG>mif</STRONG></A>
|
wolffd@0
|
373 <DD>Generates Frame Maker MIF files.
|
wolffd@0
|
374
|
wolffd@0
|
375 <DT><A NAME=d:mp HREF=#a:mp><STRONG>mp</STRONG></A>
|
wolffd@0
|
376 <DD>Produces <A HREF="http://cm.bell-labs.com/who/hobby/MetaPost.html">MetaPost</A> output.
|
wolffd@0
|
377
|
wolffd@0
|
378 <DT><A NAME=d:pcl HREF=#a:pcl><STRONG>pcl</STRONG></A>
|
wolffd@0
|
379 <DD>Produces output in the PCL printer language.
|
wolffd@0
|
380 <A HREF=#d:hpgl>HP-GL</A> is a subset of
|
wolffd@0
|
381 PCL, so that PCL output is the same as HP-GL, wrapped with some initial
|
wolffd@0
|
382 and final commands to set the printer to and from HP-GL mode.
|
wolffd@0
|
383
|
wolffd@0
|
384 <DT><A NAME=d:pdf HREF=#a:pdf><STRONG>pdf</STRONG></A>
|
wolffd@0
|
385 <DD>Produces <A HREF="http://www.adobe.com/devnet/pdf/">PDF</A> output.
|
wolffd@0
|
386 (This option assumes Graphviz includes the Cairo renderer.)
|
wolffd@0
|
387 Alternatively, one can use the <A HREF="#d:ps2">ps2</A> option to
|
wolffd@0
|
388 produce PDF-compatible PostScript, and then use a ps-to-pdf converter.
|
wolffd@0
|
389 <P>
|
wolffd@0
|
390 Note: At present, this option does not support anchors, etc. To get these
|
wolffd@0
|
391 included in your PDF output, use <A HREF="#d:ps2">ps2</A>.
|
wolffd@0
|
392
|
wolffd@0
|
393 <DT><A NAME=d:pic HREF=#a:pic><STRONG>pic</STRONG></A>
|
wolffd@0
|
394 <DD>Outputs in PIC, the picture description language in the troff-family
|
wolffd@0
|
395
|
wolffd@0
|
396 <DT><A NAME=d:plain HREF=#a:plain><STRONG>plain</STRONG></A>
|
wolffd@0
|
397 ,<DT><A NAME=d:plain-ext HREF=#a:plain-ext><STRONG>plain-ext</STRONG></A>
|
wolffd@0
|
398 <DD>The plain and plain-ext formats produce output using
|
wolffd@0
|
399 a simple, line-based language.
|
wolffd@0
|
400 The latter format differs in that, on edges, it provides port names
|
wolffd@0
|
401 on head and tail nodes when applicable.
|
wolffd@0
|
402 <P>
|
wolffd@0
|
403 There are four types of statements.
|
wolffd@0
|
404 <PRE>
|
wolffd@0
|
405 <STRONG>graph</STRONG> <I>scale</I> <I>width</I> <I>height</I>
|
wolffd@0
|
406 <STRONG>node</STRONG> <I>name</I> <I>x</I> <I>y</I> <I>width</I> <I>height</I> <I>label</I> <I>style</I> <I>shape</I> <I>color</I> <I>fillcolor</I>
|
wolffd@0
|
407 <STRONG>edge</STRONG> <I>tail</I> <I>head</I> <I>n</I> <I>x<sub>1</sub></I> <I>y<sub>1</sub></I> .. <I>x<sub>n</sub></I> <I>y<sub>n</sub></I> [<I>label</I> <I>xl</I> <I>yl</I>] <I>style</I> <I>color</I>
|
wolffd@0
|
408 <STRONG>stop</STRONG>
|
wolffd@0
|
409 </PRE>
|
wolffd@0
|
410 <DL>
|
wolffd@0
|
411 <DT><STRONG>graph</STRONG>
|
wolffd@0
|
412 <DD>The <I>width</I> and <I>height</I> values give the width and height
|
wolffd@0
|
413 of the drawing. The lower left corner of the drawing is at the origin.
|
wolffd@0
|
414 The <I>scale</I> value indicates how the drawing should be scaled
|
wolffd@0
|
415 if a <A HREF=attrs.html#d:size>size</A> attribute was given and the drawing
|
wolffd@0
|
416 needs to be scaled to conform to that size. If no scaling is necessary,
|
wolffd@0
|
417 it will be set to 1.0. Note that all graph, node and edge
|
wolffd@0
|
418 coordinates and lengths are given unscaled.
|
wolffd@0
|
419 <DT><STRONG>node</STRONG>
|
wolffd@0
|
420 <DD>The <I>name</I> value is the name of the node, and <I>x</I> and <I>y</I>
|
wolffd@0
|
421 give the node's position. The <I>width</I> and <I>height</I> are the
|
wolffd@0
|
422 width and height of the node.
|
wolffd@0
|
423 The <I>label</I>,
|
wolffd@0
|
424 <I>style</I>, <I>shape</I>, <I>color</I> and <I>fillcolor</I> give the
|
wolffd@0
|
425 node's <A HREF=attrs.html#d:label>label</A>,
|
wolffd@0
|
426 <A HREF=attrs.html#d:style>style</A>, <A HREF=attrs.html#d:shape>shape</A>,
|
wolffd@0
|
427 <A HREF=attrs.html#d:color>color</A> and
|
wolffd@0
|
428 <A HREF=attrs.html#d:fillcolor>fillcolor</A>,
|
wolffd@0
|
429 respectively, using attribute default values where necessary. If the
|
wolffd@0
|
430 node does not have a style attribute, "solid" is used.
|
wolffd@0
|
431 <DT><STRONG>edge</STRONG>
|
wolffd@0
|
432 <DD>The <I>tail</I> and <I>head</I> values give the names of the head and
|
wolffd@0
|
433 tail nodes. In plain-ext format, the head or tail name will be appended
|
wolffd@0
|
434 with a colon and a portname if the edge connects to the node at a port.
|
wolffd@0
|
435 <I>n</I> is the number of control points defining the
|
wolffd@0
|
436 B-spline forming the edge. This is followed by 2*<I>n</I> numbers giving
|
wolffd@0
|
437 the x and y coordinates of the control points in order from tail to head.
|
wolffd@0
|
438 If the edge has a <A HREF=attrs.html#d:label>label</A>, this comes next
|
wolffd@0
|
439 followed by the x and y coordinates of the label's position.
|
wolffd@0
|
440 The edge description is completed by the edge's
|
wolffd@0
|
441 <A HREF=attrs.html#d:style>style</A> and <A HREF=attrs.html#d:color>color</A>.
|
wolffd@0
|
442 As with nodes, if a style is not defined, "solid" is used.
|
wolffd@0
|
443 <P>
|
wolffd@0
|
444 <B>Note:</B> The control points given in an edge statement define the
|
wolffd@0
|
445 body of the edge. In particular, if the edge has an arrowhead to the
|
wolffd@0
|
446 head or tail node,
|
wolffd@0
|
447 there will be a gap between the last or first control points and the
|
wolffd@0
|
448 boundary of the associated node. There are at least 3 possible ways
|
wolffd@0
|
449 of handling this gap:
|
wolffd@0
|
450 <UL>
|
wolffd@0
|
451 <LI> Arrange that the input graph uses <TT>dir=none</TT>,
|
wolffd@0
|
452 <TT>arrowhead=none</TT>, or <TT>arrowtail=none</TT> for all edges.
|
wolffd@0
|
453 In this case, the terminating control points will always touch the node.
|
wolffd@0
|
454 <LI> Consider the line segment joining the control point and the center
|
wolffd@0
|
455 of the node, and determine the point where the segment intersects the
|
wolffd@0
|
456 node's boundary. Then use the control point and the intersection point
|
wolffd@0
|
457 as the main axis of an arrowhead. The problem with this approach is
|
wolffd@0
|
458 that, if the edge has a port, the edge will not be pointing to the
|
wolffd@0
|
459 center of the node. In this case, rather than use the control point
|
wolffd@0
|
460 and center point, one can use the control point and its tangent.
|
wolffd@0
|
461 <LI> Arrange that the input graph uses <TT>headclip=false</TT> or
|
wolffd@0
|
462 <TT>tailclip=false</TT>. In this case, the edge will terminate at
|
wolffd@0
|
463 the node's center rather than its boundary. If arrowheads are used,
|
wolffd@0
|
464 there will still be a gap, but normally this will occur within the
|
wolffd@0
|
465 node. The application will still need to clip the spline to the node
|
wolffd@0
|
466 boundary. Also, as with the previous item, if the edge points to
|
wolffd@0
|
467 a node port, this technique will fail.
|
wolffd@0
|
468 </UL>
|
wolffd@0
|
469 </DL>
|
wolffd@0
|
470 The output consists of one <STRONG>graph</STRONG> line, a sequence of
|
wolffd@0
|
471 <STRONG>node</STRONG> lines, one per node, a sequence of
|
wolffd@0
|
472 <STRONG>edge</STRONG> lines, one per edge, and a final <STRONG>stop</STRONG>
|
wolffd@0
|
473 line. All units are in inches, represented by a floating point number.
|
wolffd@0
|
474 <P>
|
wolffd@0
|
475 Note that the plain formats provide minimal information, really giving not
|
wolffd@0
|
476 much more than node positions and sizes, and edge spline control points.
|
wolffd@0
|
477 These formats are usually most useful to applications wanting just this
|
wolffd@0
|
478 geometric information, and willing to fill in all of the graphical details.
|
wolffd@0
|
479 The only real advantages to these formats is their terseness and their
|
wolffd@0
|
480 ease of parsing. In general, the <A HREF=#d:dot>dot</A> and
|
wolffd@0
|
481 <A HREF=#d:xdot>xdot</A> are preferable in terms of the quantity of
|
wolffd@0
|
482 information provided.
|
wolffd@0
|
483
|
wolffd@0
|
484 <DT><A NAME=d:png HREF=#a:png><STRONG>png</STRONG></A>
|
wolffd@0
|
485 <DD>Produces output in the PNG (Portable Network Graphics) format.
|
wolffd@0
|
486
|
wolffd@0
|
487 <DT><A NAME=d:ps HREF=#a:ps><STRONG>ps</STRONG></A>
|
wolffd@0
|
488 <DD>Produces PostScript output.
|
wolffd@0
|
489 <P>
|
wolffd@0
|
490 Note: The default PostScript renderer can only handle the Latin-1
|
wolffd@0
|
491 character set. To get non-Latin-1 characters into PostScript output,
|
wolffd@0
|
492 use <TT>-Tps:cairo</TT>, assuming your version was built with the
|
wolffd@0
|
493 Cairo renderer.
|
wolffd@0
|
494
|
wolffd@0
|
495 <DT><A NAME=d:ps2 HREF=#a:ps2><STRONG>ps2</STRONG></A>
|
wolffd@0
|
496 <DD>Produces PostScript output with PDF notations. It is assumed the output
|
wolffd@0
|
497 will be directly converted into PDF format. The notations include PDF
|
wolffd@0
|
498 bounding box information, so that the resulting PDF file can be correctly
|
wolffd@0
|
499 used with pdf tools, such as <STRONG>pdflatex</STRONG>.
|
wolffd@0
|
500 In addition, if a node has a URL
|
wolffd@0
|
501 attribute, this gets translated into PDF code such that the node,
|
wolffd@0
|
502 when viewed in a PDF-viewer, e.g.,
|
wolffd@0
|
503 <STRONG>acroread</STRONG>,
|
wolffd@0
|
504 is a link to the given URL. If a URL is attached to the graph, this serves
|
wolffd@0
|
505 as a base, such that relative URLs on nodes are derived from it.
|
wolffd@0
|
506
|
wolffd@0
|
507 <DT><A NAME=d:svg HREF=#a:svg><STRONG>svg</STRONG></A>
|
wolffd@0
|
508 ,<DT><A NAME=d:svgz HREF=#a:svgz><STRONG>svgz</STRONG></A>
|
wolffd@0
|
509 <DD>Produce <A HREF="http://www.adobe.com/svg/">SVG</A> output,
|
wolffd@0
|
510 the latter in compressed format.
|
wolffd@0
|
511 <P>
|
wolffd@0
|
512 See <A HREF=#ID>Note</A>.
|
wolffd@0
|
513
|
wolffd@0
|
514 <DT><A NAME=d:tga HREF=#a:tga><STRONG>tga</STRONG></A>
|
wolffd@0
|
515 <DD>Produces <A HREF="http://en.wikipedia.org/wiki/Truevision_TGA">Targa</A> output.
|
wolffd@0
|
516
|
wolffd@0
|
517 <DT><A NAME=d:tif HREF=#a:tif><STRONG>tif</STRONG></A>
|
wolffd@0
|
518 ,<DT><A NAME=d:tiff HREF=#a:tiff><STRONG>tiff</STRONG></A>
|
wolffd@0
|
519 <DD>Produces <A HREF="http://www.libtiff.org/">TIFF</A> output.
|
wolffd@0
|
520
|
wolffd@0
|
521 <DT><A NAME=d:vml HREF=#a:vml><STRONG>vml</STRONG></A>
|
wolffd@0
|
522 ,<DT><A NAME=d:vmlz HREF=#a:vmlz><STRONG>vmlz</STRONG></A>
|
wolffd@0
|
523 <DD>Produces <A HREF="http://www.w3.org/TR/NOTE-VML">VML</A> output,
|
wolffd@0
|
524 the latter in compressed format.
|
wolffd@0
|
525 <P>
|
wolffd@0
|
526 See <A HREF=#ID>Note</A>.
|
wolffd@0
|
527
|
wolffd@0
|
528 <DT><A NAME=d:vrml HREF=#a:vrml><STRONG>vrml</STRONG></A>
|
wolffd@0
|
529 <DD>Outputs graphs in the <A HREF="http://www.vrml.org/">VRML</A> format.
|
wolffd@0
|
530 To get a 3D embedding, nodes must have a <A HREF=attrs.html#d:z>z</A>
|
wolffd@0
|
531 attribute. These can either be supplied as part of the input graph, or
|
wolffd@0
|
532 be generated by neato provided <A HREF=attrs.html#d:dim>dim</A><TT>=3</TT>
|
wolffd@0
|
533 and at least one node has a <B>z</B> value.
|
wolffd@0
|
534 <P>
|
wolffd@0
|
535 Line segments are drawn as cylinders.
|
wolffd@0
|
536 In general, VRML output relies on having the PNG library to produce images
|
wolffd@0
|
537 used to texture-fill the node shapes. However, if
|
wolffd@0
|
538 <A HREF=attrs.html#d:shape>shape</A><TT>=point</TT>,
|
wolffd@0
|
539 a node is drawn as a 3D sphere.
|
wolffd@0
|
540
|
wolffd@0
|
541 <DT><A NAME=d:vtx HREF=#a:vtx><STRONG>vtx</STRONG></A>
|
wolffd@0
|
542 <DD>Generates graph diagrams in the format for
|
wolffd@0
|
543 <A HREF="http://www.bombshellstudios.com/samples/co/vt.html">Confluents's Visual Thought</A>.
|
wolffd@0
|
544
|
wolffd@0
|
545 <DT><A NAME=d:wbmp HREF=#a:wbmp><STRONG>wbmp</STRONG></A>
|
wolffd@0
|
546 <DD>Produces output in the Wireless BitMap (WBMP) format, optimized for
|
wolffd@0
|
547 mobile computing.
|
wolffd@0
|
548
|
wolffd@0
|
549 <DT><A NAME=d:xlib HREF=#a:xlib><STRONG>xlib</STRONG></A>
|
wolffd@0
|
550 <DD>Creates an <A HREF="http://en.wikipedia.org/wiki/Xlib">Xlib</A> window and displays the output there.
|
wolffd@0
|
551
|
wolffd@0
|
552 </DL>
|
wolffd@0
|
553 <HR>
|
wolffd@0
|
554 </BODY>
|
wolffd@0
|
555 </HTML>
|
wolffd@0
|
556 <H1 align=CENTER><A NAME=d:image_fmts>Image Formats</A></H1>
|
wolffd@0
|
557 <HR>
|
wolffd@0
|
558 The <A HREF=attrs.html#a:image>image</A> and <A HREF=attrs.html#a:shapefile>shapefile</A> attributes specify an image file to be included
|
wolffd@0
|
559 as part of the final diagram. Not all image formats can be read. In addition,
|
wolffd@0
|
560 even if read, not all image formats can necessarily be used in a given
|
wolffd@0
|
561 output format.
|
wolffd@0
|
562 <P>
|
wolffd@0
|
563 The graph below shows what image formats can be used in which output formats,
|
wolffd@0
|
564 and the required plugins. On the left are the supported image formats.
|
wolffd@0
|
565 On the right are the supported output formats.
|
wolffd@0
|
566 In the middle are the plugins: image loaders, renderers, drivers, arranged by
|
wolffd@0
|
567 plugin library.
|
wolffd@0
|
568 This presents the most general case. A given installation may not provide
|
wolffd@0
|
569 one of the plugins, in which case, that transformation is not possible.
|
wolffd@0
|
570 <BR>
|
wolffd@0
|
571 <IMG WIDTH="80%" SRC="plugins.png">
|
wolffd@0
|
572 <HR>
|
wolffd@0
|
573 <H2>Notes</H2>
|
wolffd@0
|
574 <OL TYPE="1">
|
wolffd@0
|
575 <LI>
|
wolffd@0
|
576 <A NAME=ID>In the formats: -Tcmap, -Tcmapx, -Tsvg, -Tvml, the output generates
|
wolffd@0
|
577 'id="node#"' properties for nodes, 'id="edge#"' properties for edges, and 'id="cluster#"' properties for clusters, with the '#' replaced by an internally assigned integer. These strings can be provided instead by an externally provided "id=xxx" attribute on the object.
|
wolffd@0
|
578 Normal "\N" "\E" "\G" substitutions are applied.
|
wolffd@0
|
579 Externally provided id values are not used internally, and it is the use's reponsibilty to ensure
|
wolffd@0
|
580 that they are sufficiently unique for their intended downstream use.
|
wolffd@0
|
581 Note, in particular, that "\E" is not a unique id for multiedges.
|
wolffd@0
|
582 </OL>
|