This tutorial is intended for new users of PGF and TikZ. It does not give an exhaustive account of all the features of TikZ or PGF, just of those that you are likely to use right away.
Karl is a math and chemistry high-school teacher. He used to create the graphics in his worksheets and exams using LATEX’s {picture} environment. While the results were acceptable, creating the graphics often turned out to be a lengthy process. Also, there tended to be problems with lines having slightly wrong angles and circles also seemed to be hard to get right. Naturally, his students could not care less whether the lines had the exact right angles and they find Karl’s exams too difficult no matter how nicely they were drawn. But Karl was never entirely satisfied with the result.
Karl’s son, who was even less satisfied with the results (he did not have to take the exams, after all), told Karl that he might wish to try out a new package for creating graphics. A bit confusingly, this package seems to have two names: First, Karl had to download and install a package called PGF. Then it turns out that inside this package there is another package called TikZ, which is supposed to stand for “TikZ ist kein Zeichenprogramm.” Karl finds this all a bit strange and TikZ seems to indicate that the package does not do what he needs. However, having used GNU software for quite some time and “GNU not being Unix,” there seems to be hope yet. His son assures him that TikZ’s name is intended to warn people that TikZ is not a program that you can use to draw graphics with your mouse or tablet. Rather, it is more like a “graphics language.”
Karl wants to put a graphic on the next worksheet for his students. He is currently teaching his students about sine and cosine. What he would like to have is something that looks like this (ideally):
In TikZ, to draw a picture, at the start of the picture you need to tell TEX or LATEX that you want to start a picture. In LATEX this is done using the environment {tikzpicture}, in plain TEX you just use \tikzpicture to start the picture and \endtikzpicture to end it.
Karl, being a LATEX user, thus sets up his file as follows:
|
When executed, that is, run via pdflatex or via latex followed by dvips, the resulting will contain something that looks like this:
We are working on. |
|
Admittedly, not quite the whole picture, yet, but we do have the axes established. Well, not quite, but we have the lines that make up the axes drawn. Karl suddenly has a sinking feeling that the picture is still some way off.
Let’s have a more detailed look at the code. First, the package tikz is loaded. This package is a so-called “frontend” to the basic PGF system. The basic layer, which is also described in this manual, is somewhat more, well, basic and thus harder to use. The frontend makes things easier by providing a simpler syntax.
Inside the environment there are two \draw commands. They mean: “The path, which is specified following the command up to the semicolon, should be drawn.” The first path is specified as (-1.5,0) -- (0,1.5), which means “a straight line from the point at position (-1.5,0) to the point at position (0,1.5).” Here, the positions are specified within a special coordinate system in which, initially, one unit is 1cm.
Karl is quite pleased to note that the environment automatically reserves enough space to encompass the picture.
Karl’s wife Gerda, who also happens to be a math teacher, is not a LATEX user, but uses plain TEX since she prefers to do things “the old way.” She can also use TikZ. Instead of \usepackage{tikz} she has to write \input tikz.tex and instead of \begin{tikzpicture} she writes \tikzpicture and instead of \end{tikzpicture} she writes \endtikzpicture.
Thus, she would use:
|
Gerda can typeset this file using either pdftex or tex together with dvips. TikZ will automatically discern which driver she is using. If she wishes to use dvipdfm together with tex, she either needs to modify the file pgf.cfg or can write \def\pgfsysdriver{pgfsys-dvipdfm.def} somewhere before she inputs tikz.tex or pgf.tex.
The basic building block of all pictures in TikZ is the path. A path is a series of straight lines and curves that are connected (that is not the whole picture, but let us ignore the complications for the moment). You start a path by specifying the coordinates of the start position as a point in round brackets, as in (0,0). This is followed by a series of “path extension operations.” The simplest is --, which we used already. It must be followed by another coordinate and it extends the path in a straight line to this new position. For example, if we were to turn the two paths of the axes into one path, the following would result:
|
Karl is a bit confused by the fact that there is no {tikzpicture} environment, here. Instead, the little command \tikz is used. This command either takes one argument (starting with an opening brace as in \tikz{\draw (0,0) -- (1.5,0)}, which yields ) or collects everything up to the next semicolon and puts it inside a {tikzpicture} environment. As a rule of thumb, all TikZ graphic drawing commands must occur as an argument of \tikz or inside a {tikzpicture} environment. Fortunately, the command \draw will only be defined inside this environment, so there is little chance that you will accidentally do something wrong here.
The next thing Karl wants to do is to draw the circle. For this, straight lines obviously will not do. Instead, we need some way to draw curves. For this, TikZ provides a special syntax. One or two “control points” are needed. The math behind them is not quite trivial, but here is the basic idea: Suppose you are at point x and the first control point is y. Then the curve will start “going in the direction of y at x,” that is, the tangent of the curve at x will point toward y. Next, suppose the curve should end at z and the second support point is w. Then the curve will, indeed, end at z and the tangent of the curve at point z will go through w.
Here is an example (the control points have been added for clarity):
|
The general syntax for extending a path in a “curved” way is .. controls <first control point>and <second control point>.. <end point>. You can leave out the and <second control point>, which causes the first one to be used twice.
So, Karl can now add the first half circle to the picture:
|
Karl is happy with the result, but finds specifying circles in this way to be extremely awkward. Fortunately, there is a much simpler way.
In order to draw a circle, the path construction operation circle can be used. This operation is followed by a radius in round brackets as in the following example: (Note that the previous position is used as the center of the circle.)
|
You can also append an ellipse to the path using the ellipse operation. Instead of a single radius you can specify two of them, one for the x-direction and one for the y-direction, separated by and:
|
To draw an ellipse whose axes are not horizontal and vertical, but point in an arbitrary direction (a “turned ellipse” like ) you can use transformations, which are explained later. The code for the little ellipse is \tikz \draw[rotate=30] (0,0) ellipse (6pt and 3pt);, by the way.
So, returning to Karl’s problem, he can write \draw (0,0) circle (1cm); to draw the circle:
|
At this point, Karl is a bit alarmed that the circle is so small when he wants the final picture to be much bigger. He is pleased to learn that TikZ has powerful transformation options and scaling everything by a factor of three is very easy. But let us leave the size as it is for the moment to save some space.
The next things we would like to have is the grid in the background. There are several ways to produce it. For example, one might draw lots of rectangles. Since rectangles are so common, there is a special syntax for them: To add a rectangle to the current path, use the rectangle path construction operation. This operation should be followed by another coordinate and will append a rectangle to the path such that the previous coordinate and the next coordinates are corners of the rectangle. So, let us add two rectangles to the picture:
|
While this may be nice in other situations, this is not really leading anywhere with Karl’s problem: First, we would need an awful lot of these rectangles and then there is the border that is not “closed.”
So, Karl is about to resort to simply drawing four vertical and four horizontal lines using the nice \draw command, when he learns that there is a grid path construction operation.
The grid path operation adds a grid to the current path. It will add lines making up a grid that fills the rectangle whose one corner is the current point and whose other corner is the point following the grid operation. For example, the code \tikz \draw[step=2pt] (0,0) grid (10pt,10pt); produces . Note how the optional argument for \draw can be used to specify a grid width (there are also xstep and ystep to define the steppings independently). As Karl will learn soon, there are lots of things that can be influenced using such options.
For Karl, the following code could be used:
|
Having another look at the desired picture, Karl notices that it would be nice for the grid to be more subdued. (His son told him that grids tend to be distracting if they are not subdued.) To subdue the grid, Karl adds two more options to the \draw command that draws the grid. First, he uses the color gray for the grid lines. Second, he reduces the line width to very thin. Finally, he swaps the ordering of the commands so that the grid is drawn first and everything else on top.
|
Instead of the options gray,very thin Karl could also have said style=help lines. Styles are predefined sets of options that can be used to organize how a graphic is drawn. By saying style=help lines you say “use the style that I (or someone else) has set for drawing help lines.” If Karl decides, at some later point, that grids should be drawn, say, using the color blue!50 instead of gray, he could say the following:
|
Alternatively, he could have said the following:
|
This would have added the color=blue!50 option. The help lines style would now contain two color options, but the second would override the first.
Using styles makes your graphics code more flexible. You can change the way things look easily in a consistent manner.
To build a hierarchy of styles you can have one style use another. So in order to define a style Karl's grid that is based on the grid style Karl could say
|
You can also leave out the style=. Thus, whenever TikZ encounters an options that it does not know about, it will check whether this option happens to be the name of a style. If so, the style is used. Thus, Karl could also have written:
|
For some styles, like the very thin style, it is pretty clear what the style does and there is no need to say style=very thin. For other styles, like help lines, it seems more natural to me to say style=help lines. But, mainly, this is a matter of taste.
Karl wonders what other options there are that influence how a path is drawn. He saw already that the color=<color> option can be used to set the line’s color. The option draw=<color> does nearly the same, only it sets the color for the lines only and a different color can be used for filling (Karl will need this when he fills the arc for the angle).
He saw that the style very thin yields very thin lines. Karl is not really surprised by this and neither is he surprised to learn that thin yields thin lines, thick yields thick lines, very thick yields very thick lines, ultra thick yields really, really thick lines and ultra thin yields lines that are so thin that low-resolution printers and displays will have trouble showing them. He wonders what gives lines of “normal” thickness. It turns out that thin is the correct choice. This seems strange to Karl, but his son explains him that LATEX has two commands called \thinlines and \thicklines and that \thinlines gives the line width of “normal” lines, more precisely, of the thickness that, say, the stem of a letter like “T” or “i” has. Nevertheless, Karl would like to know whether there is anything “in the middle” between thin and thick. There is: semithick.
Another useful thing one can do with lines is to dash or dot them. For this, the two styles dashed and dotted can be used, yielding and . Both options also exist in a loose and a dense version, called loosely dashed, densely dashed, loosely dotted, and densely dotted. If he really, really needs to, Karl can also define much more complex dashing patterns with the dash pattern option, but his son insists that dashing is to be used with utmost care and mostly distracts. Karl’s son claims that complicated dashing patterns are evil. Karl’s students do not care about dashing patterns.
Our next obstacle is to draw the arc for the angle. For this, the arc path construction operation is useful, which draws part of a circle or ellipse. This arc operation must be followed by a triple in rounded brackets, where the components of the triple are separated by colons. The first two components are angles, the last one is a radius. An example would be (10:80:10pt), which means “an arc from 10 degrees to 80 degrees on a circle of radius 10pt.” Karl obviously needs an arc from 0o to 30o. The radius should be something relatively small, perhaps around one third of the circle’s radius. This gives: (0:30:3mm).
When one uses the arc path construction operation, the specified arc will be added with its starting point at the current position. So, we first have to “get there.”
|
Karl thinks this is really a bit small and he cannot continue unless he learns how to do scaling. For this, he can add the [scale=3] option. He could add this option to each \draw command, but that would be awkward. Instead, he adds it to the whole environment, which causes this option to apply to everything within.
|
As for circles, you can specify “two” radii in order to get an elliptical arc.
|
In order to save space in this manual, it would be nice to clip Karl’s graphics a bit so that we can focus on the “interesting” parts. Clipping is pretty easy in TikZ. You can use the \clip command clip all subsequent drawing. It works like \draw, only it does not draw anything, but uses the given path to clip everything subsequently.
|
You can also do both at the same time: Draw and clip a path. For this, use the \draw command and add the clip option. (This is not the whole picture: You can also use the \clip command and add the draw option. Well, that is also not the whole picture: In reality, \draw is just a shorthand for \path[draw] and \clip is a shorthand for \path[clip] and you could also say \path[draw,clip].) Here is an example:
|
Although Karl does not need them for his picture, he is pleased to learn that there are parabola and sin and cos path operations for adding parabolas and sine and cosine curves to the current path. For the parabola operation, the current point will lie on the parabola as well as the point given after the parabola operation. Consider the following example:
|
It is also possible to place the bend somewhere else:
|
The operations sin and cos add a sine or cosine curve in the interval [0,/2] such that the previous current point is at the start of the curve and the curve ends at the given end point. Here are two examples:
A sine curve. |
|
|
Returning to the picture, Karl now wants the angle to be “filled” with a very light green. For this he uses \fill instead of \draw. Here is what Karl does:
|
The color green!20!white means 20% green and 80% white mixed together. Such color expression are possible since PGF uses Uwe Kern’s xcolor package, see the documentation of that package for details on color expressions.
What would have happened, if Karl had not “closed” the path using --(0,0) at the end? In this case, the path is closed automatically, so this could have been omitted. Indeed, it would even have been better to write the following, instead:
|
The --cycle causes the current path to be closed (actually the current part of the current path) by smoothly joining the first and last point. To appreciate the difference, consider the following example:
|
You can also fill and draw a path at the same time using the \filldraw command. This will first draw the path, then fill it. This may not seem too useful, but you can specify different colors to be used for filling and for stroking. These are specified as optional arguments like this:
|
Karl briefly considers the possibility of making the angle “more fancy” by shading it. Instead of filling the with a uniform color, a smooth transition between different colors is used. For this, \shade and \shadedraw, for shading and drawing at the same time, can be used:
|
The default shading is a smooth transition from gray to white. To specify different colors, you can use options:
|
For Karl, the following might be appropriate:
|
However, he wisely decides that shadings usually only distract without adding anything to the picture.
Karl now wants to add the sine and cosine lines. He knows already that he can use the color= option to set the lines’s colors. So, what is the best way to specify the coordinates?
There are different ways of specifying coordinates. The easiest way is to say something like (10pt,2cm). This means 10pt in x-direction and 2cm in y-directions. Alternatively, you can also leave out the units as in (1,2), which means “one times the current x-vector plus twice the current y-vector.” These vectors default to 1cm in the x-direction and 1cm in the y-direction, respectively.
In order to specify points in polar coordinates, use the notation (30:1cm), which means 1cm in direction 30 degree. This is obviously quite useful to “get to the point (cos30o,sin30o) on the circle.”
You can add a single + sign in front of a coordinate or two of them as in +(1cm,0cm) or ++(0cm,2cm). Such coordinates are interpreted differently: The first form means “1cm upwards from the previous specified position” and the second means “2cm to the right of the previous specified position, making this the new specified position.” For example, we can draw the sine line as follows:
|
Karl used the fact sin30o = 1/2. However, he very much doubts that his students know this, so it would be nice to have a way of specifying “the point straight down from (30:1cm) that lies on the x-axis.” This is, indeed, possible using a special syntax: Karl can write (30:1cm |- 0,0). In general, the meaning of (<p> |- <q>) is “the intersection of a vertical line through p and a horizontal line through q.”
Next, let us draw the cosine line. One way would be to say (30:1cm |- 0,0) -- (0,0). Another way is the following: we “continue” from where the sine ends:
|
Note the there is no -- between (30:1cm) and +(0,-0.5). In detail, this path is interpreted as follows: “First, the (30:1cm) tells me to move by pen to (cos30o,1/2). Next, there comes another coordinate specification, so I move my pen there without drawing anything. This new point is half a unit down from the last position, thus it is at (cos30o,0). Finally, I move the pen to the origin, but this time drawing something (because of the --).”
To appreciate the difference between + and ++ consider the following example:
|
By comparison, when using a single +, the coordinates are different:
|
Naturally, all of this could have been written more clearly and more economically like this (either with a single of a double +):
|
Karl is left with the line for tan, which seems difficult to specify using transformations and polar coordinates. For this he needs another way of specifying coordinates: Karl can specify intersections of lines as coordinates. The line for tan starts at (1,0) and goes upward to a point that is at the intersection of a line going “up” and a line going from the origin through (30:1cm). The syntax for this point is the following:
|
In the following, two final examples of how to use relative positioning are presented. Note that the transformation options, which are explained later, are often more useful for shifting than relative positioning.
|
Karl now wants to add the little arrow tips at the end of the axes. He has noticed that in many plots, even in scientific journals, these arrow tips seem to missing, presumably because the generating programs cannot produce them. Karl thinks arrow tips belong at the end of axes. His son agrees. His students do not care about arrow tips.
It turns out that adding arrow tips is pretty easy: Karl adds the option -> to the drawing commands for the axes:
|
If Karl had used the option <- instead of ->, arrow tips would have been put at the beginning of the path. The option <-> puts arrow tips at both ends of the path.
There are certain restrictions to the kind of paths to which arrow tips can be added. As a rule of thumb, you can add arrow tips only to a single open “line.” For example, you should not try to add tips to, say, a rectangle or a circle. (You can try, but no guarantees as to what will happen now or in future versions.) However, you can add arrow tips to curved paths and to paths that have several segments, as in the following examples:
|
Karl has a more detailed look at the arrow that TikZ puts at the end. It looks like this when he zooms it: . The shape seems vaguely familiar and, indeed, this is exactly the end of TEX’s standard arrow used in something like f : A B.
Karl likes the arrow, especially since it is not “as thick” as the arrows offered by many other packages. However, he expects that, sometimes, he might need to use some other kinds of arrow. To do so, Karl can say >=<right arrow tip kind>, where <right arrow tip kind> is a special arrow tip specification. For example, if Karl says >=stealth, then he tells TikZ that he would like “stealth-fighter-like” arrow tips:
|
Karl wonders whether such a military name for the arrow type is really necessary. He is not really mollified when his son tells him that Microsoft’s PowerPoint uses the same name. He decides to have his students discuss this at some point.
In addition to stealth there are several other predefined arrow tip kinds Karl can choose from, see Section 14.1. Furthermore, he can define arrows types himself, if he needs new ones.
Karl saw already that there are numerous graphic options that affect how paths are rendered. Often, he would like to apply certain options to a whole set of graphic commands. For example, Karl might wish to draw three paths using a thick pen, but would like everything else to be drawn “normally.”
If Karl wishes to set a certain graphic option for the whole picture, he can simply pass this option to the \tikz command or to the {tikzpicture} environment (Gerda would pass the options to \tikzpicture). However, if Karl wants to apply graphic options to a local group, he put these commands inside a {scope} environment (Gerda uses \scope and \endscope). This environment takes graphic options as an optional argument and these options apply to everything inside the scope, but not to anything outside.
Here is an example:
|
Scoping has another interesting effect: Any changes to the clipping area are local to the scope. Thus, if you say \clip somewhere inside a scope, the effect of the \clip command ends at the end of the scope. This is useful since there is no other way of “enlarging” the clipping area.
Karl has also already seen that giving options to commands like \draw apply only to that command. In turns out that the situation is slightly more complex. First, options to a command like \draw are not really options to the command, but they are “path options” and can be given anywhere on the path. So, instead of \draw[thin] (0,0) -- (1,0); one can also write \draw (0,0) [thin] -- (1,0); or \draw (0,0) -- (1,0) [thin];; all of these have the same effect. This might seem strange since in the last case, it would appear that the thin should take effect only “after” the line from (0,0) to (1,0) has been draw. However, most graphic options only apply to the whole path. Indeed, if you say both thin and thick on the same path, the last option given will “win.”
When reading the above, Karl notices that only “most” graphic options apply to the whole path. Indeed, all transformation options do not apply to the whole path, but only to “everything following them on the path.” We will have a more detailed look at this in a moment. Nevertheless, all options given during a path construction apply only to this path.
When you specify a coordinate like (1cm,1cm), where is that coordinate placed on the page? To determine the position, TikZ, TEX, and PDF or PostScript all apply certain transformations to the given coordinate in order to determine the finally position on the page.
TikZ provides numerous options that allow you to transform coordinates in PGF’s private coordinate system. For example, the xshift option allows you to shift all subsequent points by a certain amount:
|
It is important to note that you can change transformation “in the middle of a path,” a feature that is not supported by PDF or PostScript. The reason is that PGF keeps track of its own transformation matrix.
Here is a more complicated example:
|
The most useful transformations are xshift and yshift for shifting, shift for shifting to a given point as in shift={(1,0)} or shift={+(0,0)} (the braces are necessary so that TEX does not mistake the comma for separating options), rotate for rotating by a certain angle (there is also a rotate around for rotating around a given point), scale for scaling by a certain factor, xscale and yscale for scaling only in the x- or y-direction (xscale=-1 is a flip), and xslant and yslant for slanting. If these transformation and those that I have not mentioned are not sufficient, the cm option allows you to apply an arbitrary transformation matrix. Karl’s students, by the way, do not know what a transformation matrix is.
Karl’s next aim is to add little ticks on the axes at positions -1, -1/2, 1/2, and 1. For this, it would be nice to use some kind of “loop,” especially since he wishes to do the same thing at each of these positions. There are different packages for doing this. LATEX has its own internal command for this, pstricks comes along with the powerful \mulitdo command. All of these can be used together with PGF and TikZ, so if you are familiar with them, feel free to use them. PGF introduces yet another command, called \foreach, which I introduced since I could never remember the syntax of the other packages. \foreach is defined in the package pgffor and can be used independently of PGF. TikZ includes it automatically.
In its basic form, the \foreach command is easy to use:
x = 1, x = 2, x = 3, |
|
The general syntax is \foreach <variable> in {<list of values>} <commands>. Inside the <commands>, the <variable> will be assigned to the different values. If the <commands> do not start with a brace, everything up to the next semicolon is used as <commands>.
For Karl and the ticks on the axes, he could use the following code:
|
As a matter of fact, there are many different ways of creating the ticks. For example, Karl could have put the \draw ...; inside curly braces. He could also have used, say,
|
Karl is curious what would happen in a more complicated situation where there are, say, 20 ticks. It seems bothersome to explicitly mention all these numbers in the set for \foreach. Indeed, it is possible to use ... inside the \foreach statement to iterate over a large number of values (which must, however, be dimensionless real numbers) as in the following example:
|
If you provide two numbers before the ..., the \foreach statement will use their difference for the stepping:
|
We can also nest loops to create interesting effects:
|
The \foreach statement can do even trickier stuff, but the above gives the idea.
Karl is, by now, quite satisfied with the picture. However, the most important parts, namely the labels, are still missing!
TikZ offers an easy-to-use and powerful system for adding text and, more generally, complex shapes to a picture at specific positions. The basic idea is the following: When TikZ is constructing a path and encounters the keyword node in the middle of a path, it reads a node specification. The keyword node is typically followed by some options and then some text between curly braces. This text is put inside a normal TEX box (if the node specification directly follows a coordinate, which is usually the case, TikZ is able to perform some magic so that it is even possible to use verbatim text inside the boxes) and then placed at the current position, that is, at the last specified position (possibly shifted a bit, according to the given options). However, all nodes are drawn only after the path has been completely drawn/filled/shaded/clipped/whatever.
|
Obviously, Karl would not only like to place nodes on the last specified position, but also to the left or the right of these positions. For this, every node object that you put in your picture is equipped with several anchors. For example, the north anchor is in the middle at the upper end of the shape, the south anchor is at the bottom and the north east anchor is in the upper right corner. When you given the option anchor=north, the text will be placed such that this northern anchor will lie on the current position and the text is, thus, below the current position. Karl uses this to draw the ticks as follows:
|
This is quite nice, already. Using these anchors, Karl can now add most of the other text elements. However, Karl thinks that, though “correct,” it is quite counter-intuitive that in order to place something below a given point, he has to use the north anchor. For this reason, there is an option called below, which does the same as anchor=north. Similarly, above right does the same as anchor=south east. In addition, below takes an optional dimension argument. If given, the shape will additionally be shifted downwards by the given amount. So, below=1pt can be used to put a text label below some point and, additionally shift it 1pt downwards.
Karl is not quite satisfied with the ticks. He would like to have 1/2 or shown instead of 0.5, partly to show off the nice capabilities of TEX and TikZ, partly because for positions like 1/3 or it is certainly very much preferable to have the “mathematical” tick there instead of just the “numeric” tick. His students, on the other hand, prefer 0.5 over 1/2 since they are not too fond of fractions in general.
Karl now faces a problem: For the \foreach statement, the position \x should still be given as 0.5 since TikZ will not know where \frac{1}{2} is supposed to be. On the other hand, the typeset text should really be \frac{1}{2}. To solve this problem, \foreach offers a special syntax: Instead of having one variable \x, Karl can specify two (or even more) variables separated by a slash as in \x / \xtext. Then, the elements in the set over which \foreach iterates must also be of the form <first>/<second>. In each iteration, \x will be set to <first> and \xtext will be set to <second>. If no <second> is given, the <first> will be used again. So, here is the new code for the ticks:
|
Karl is quite pleased with the result, but his son points out that this is still not perfectly satisfactory: The grid and the circle interfere with the numbers and decrease their legibility. Karl is not very concerned by this (his students do not even notice), but his son insists that there is an easy solution: Karl can add the [fill=white] option to fill out the background of the text shape with a white color.
The next thing Karl wants to do is to add the labels like sin. For this, he would like to place a label “in the middle of line.” To do so, instead of specifying the label node {$\sin\alpha$} directly after one of the endpoints of the line (which would place the label at that endpoint), Karl can give the label directly after the --, before the coordinate. By default, this places the label in the middle of the line, but the pos= options can be used to modify this. Also, options like near start and near end can be used to modify this position:
|
You can also position labels on curves and, by adding the sloped option, have them rotated such that they match the line’s slope. Here is an example:
|
It remains to draw the explanatory text at the right of the picture. The main difficulty here lies in limiting the width of the text “label,” which is quite long, so that line breaking is used. Fortunately, Karl can use the option text width=6cm to get the desired effect. So, here is the full code:
|
Placing text at a given position is just a special case of a more general underlying mechanism. When you say \draw (0,0) node{text};, what actually happens is that a rectangular node, anchored at its center, is put at position (0,0). On top of the rectangular node the text text is drawn. Since no action is specified for the rectangle (like draw or fill), the rectangle is actually discarded and only the text is shown. However, by adding fill or draw, we can make the underlying shape visible. Furthermore, we can change the shape using for example shape=circle or just circle. If we include the package pgflibraryshapes we also get ellipse:
|
As the above example shows, we can add the a name to a node by putting it in parentheses between node and the {<text>} (you can also use the name= option). This will make TikZ remember your node and all its anchors. You can then refer to these anchors when specifying coordinates. The syntax is (<node name>.<anchor>). Currently, and also in the near future, this will not work across pictures since TikZ looses track of the positions when it returns control to TEX. Magic hackery is possible for certain drivers, but a portable implementation seems impossible (just think of a possible SVG driver).
The option shorten > causes lines to be shortened by 2pt at the end. Similarly, shorten < can be used to shorten (or even lengthen) lines at the beginning. This is possible even if no arrow is drawn.
It is not always necessary to specify the anchor. If you do not give an anchor, TikZ will try to determine a reasonable border anchor by itself (if TikZ fails to find anything useful, it will use the center instead). Here is a typical example:
|
In the example, we used the \node command, which is an abbreviation for \path node.