-
Notifications
You must be signed in to change notification settings - Fork 6
/
tikz.tags
22188 lines (19958 loc) · 821 KB
/
tikz.tags
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
-- Copyright 2007-2013 Till Tantau
-- Copyright 2022 Augusto Stoffel, Jens Schneider
-- SPDX-License-Identifier: GFDL-1.2-or-later or LPPL-1.3c+
--
-- Adapted from the PGF manual, version 3.1.9a, which can be found at
-- https://ctan.org/pkg/pgf.
ctan_package = "tikz"
documentation = {{summary = "PGF Manual", uri = "texmf:doc/generic/pgf/pgfmanual.pdf"}}
commands = {
afterdecoration = {
arguments = {{meta = "after code"}},
details = [[
Defines ⟨after code⟩ as commands to be executed after the decoration has
been applied to the current segment. This command can be omitted.
]],
documentation = "texmf:doc/generic/pgf/pgfmanual.pdf#pgf.back/afterdecoration"
},
anchor = {
arguments = {{meta = "name"}, {meta = "code"}},
details = [[
This command declares an anchor named ⟨name⟩. Unlike for saved anchors,
the ⟨code⟩ will not be executed each time a node is declared. Rather,
the ⟨code⟩ is only executed when the anchor is specifically requested;
either for anchoring the node during its creation or as a position in
the shape referenced later on.
The ⟨name⟩ is a quite arbitrary string that is not "passed down" to the
system level. Thus, names like `south` or `1` or `::` would all be fine.
A saved anchor is not automatically also a normal anchor. If you wish to
give the users access to a saved anchor you must declare a normal anchor
that just returns the position of the saved anchor.
When the ⟨code⟩ is executed, all saved anchor macros will be defined.
Thus, you can reference them in your ⟨code⟩. The effect of the ⟨code⟩
should be to set the values of `\pgf@x` and `\pgf@y` to the coordinates
of the anchor.
Let us consider some example for the `simple rectangle` shape. First, we
would like to make the upper right corner publicly available, for
example as `north east`:
\anchor{north east}{\upperrightcorner}
The `\upperrightcorner` macro will set `\pgf@x` and `\pgf@y` to the
coordinates of the upper right corner. Thus, `\pgf@x` and `\pgf@y` will
have exactly the right values at the end of the anchor's code.
Next, let us define a `north west` anchor. For this anchor, we can
negate the `\pgf@x` variable:
\anchor{north west}{
\upperrightcorner
\pgf@x=-\pgf@x
}
Finally, it is a good idea to always define a `center` anchor, which
will be the default location for a shape.
\anchor{center}{\pgfpointorigin}
You might wonder whether we should not take into consideration that the
node is not placed at the origin, but has been shifted somewhere.
However, the anchor positions are always specified in the shape's
"private" coordinate system. The "outer" transformation that has been
applied to the shape upon its creation is applied automatically to the
coordinates returned by the anchor's ⟨code⟩.
Our `simple rectangle` only has one text label (node part) called
`text`. This is the default situation, so we do not need to do anything.
For the `text` node part we must set up a `text` anchor. Upon creation
of a node, this anchor will be made to coincide with the left endpoint
of the baseline of the text label (within the private coordinate system
of the shape). By default, the `text` anchor is at the origin, but you
may change this. For example, we would say
\anchor{text}{%
\upperrightcorner%
\pgf@x=-\pgf@x%
\pgf@y=-\pgf@y%
}
to center the text label on the origin in the shape coordinate space.
Note that we could *not* have written the following:
\anchor{text}{\pgfpoint{-.5\wd\pgfnodeparttextbox}{-.5\ht\pgfnodeparttextbox}}
Do you see why this is wrong? The problem is that the box
`\pgfnodeparttextbox` will most likely not have the correct size when
the anchor is computed. After all, the anchor position might be
recomputed at a time when several other nodes have been created.
If a shape has several node parts, we would have to define an anchor for
each part.
]],
documentation = "texmf:doc/generic/pgf/pgfmanual.pdf#pgf.back/anchor"
},
anchorborder = {
arguments = {{meta = "code"}},
details = [[
A *border anchor* is an anchor point on the border of the shape. What
exactly is considered as the "border" of the shape depends on the shape.
When the user requests a point on the border of the shape using the
`\pgfpointshapeborder` command, the ⟨code⟩ will be executed to discern
this point. When the execution of the ⟨code⟩ starts, the dimensions
`\pgf@x` and `\pgf@y` will have been set to a location $p$ in the
shape's coordinate system, and relative to the anchor `center`. Note
that `\pgfpointshapeborder` will produce an error if the shape does not
contain the `center` anchor.
It is now the job of the ⟨code⟩ to set up `\pgf@x` and `\pgf@y` such
that they specify the point on the shape's border that lies on a
straight line from the shape's center to the point $p$. Usually, this is
a somewhat complicated computation, involving many case distinctions and
some basic math. Note that the output coordinates must be returned in
the shape's coordinate system, *no longer* relative to the `center`
anchor. While these different points of reference are only noticeable if
the `center` anchor is not at the origin of the shape's coordinate
system, it implies that "doing nothing" as a border anchor, i.e.,
returning the point that was fed to `\pgfpointshapeborder` requires
adding the `center` anchor to the input coordinates.
For our `simple rectangle` we must compute a point on the border of a
rectangle whose one corner is the origin (ignoring the depth for
simplicity) and whose other corner is `\upperrightcorner`. The following
code might be used:
\anchorborder{%
% Call a function that computes a border point. Since this
% function will modify dimensions like \pgf@x, we must move them to
% other dimensions.
\@tempdima=\pgf@x
\@tempdimb=\pgf@y
\pgfpointborderrectangle{\pgfpoint{\@tempdima}{\@tempdimb}}{\upperrightcorner}
}
]],
documentation = "texmf:doc/generic/pgf/pgfmanual.pdf#pgf.back/anchorborder"
},
arrow = {
arguments = {
{
delimiters = {"[", "]"},
keys = "$ref:tikz#/keys/tikz",
meta = "options",
optional = true
},
{meta = "arrow end tip"}
},
details = [[
This command simply draws the ⟨arrow end tip⟩ at the origin, pointing
right. This is exactly what you need when you want to draw an arrow tip
as a marking.
The ⟨options⟩ can only be given when TikZ is used. In this case, they
are executed in a scope that contains the arrow tip.
\begin{tikzpicture}[decoration={
markings,% switch on markings
mark=at position 1cm with {\node[red]{1cm};},
mark=at position .75 with {\arrow[blue,line width=2mm]{>}},
mark=at position -1cm with {\arrowreversed[black]{stealth}}}
]
\draw [help lines] grid (3,2);
\draw [postaction={decorate}] (0,0) -- (3,1) arc (0:180:1.5 and 1);
\end{tikzpicture}
Here is a more useful example:
\begin{tikzpicture}[decoration={
markings,% switch on markings
mark=between positions 0 and .75 step 4mm with {\arrow{stealth}},
mark=between positions .75 and 1 step 4mm with {\arrowreversed{stealth}}}
]
\draw [help lines] grid (3,2);
\draw [postaction={decorate}] (0,0) -- (3,1) arc (0:180:1.5 and 1);
\end{tikzpicture}
]],
documentation = "texmf:doc/generic/pgf/pgfmanual.pdf#pgf.back/arrow"
},
arrowreversed = {
arguments = {
{
delimiters = {"[", "]"},
keys = "$ref:tikz#/keys/tikz",
meta = "options",
optional = true
},
{meta = "arrow end tip"}
},
details = [[
As above, only the arrow end tip is flipped and points in the other
direction.
]],
documentation = "texmf:doc/generic/pgf/pgfmanual.pdf#pgf.back/arrowreversed"
},
attribute = {
arguments = {
{meta = "attribute name"},
{literal = "="},
{meta = "initial value"},
{literal = ";"}
},
details = [[
This command can only be given inside the body of an `\pgfooclass`
command. It declares the attribute named ⟨attribute name⟩. This name,
like method or class names, can be quite arbitrary, but should not
contain periods. Valid names are `an_ attribute?` or `my attribute`.
You can optionally specify an ⟨initial value⟩ for the attribute; if none
is given, the empty string is used automatically. The initial value is
the value that the attribute will have just after the object has been
created and before the constructor is called.
\pgfooclass{stamp}{
% This is the class stamp
\attribute text;
\attribute rotation angle = 20;
\method stamp(#1) {
\pgfooset{text}{#1} % Set the text
}
\method apply(#1,#2) {
\pgfoothis.shift origin(#1,#2)
% Draw the stamp:
\node [rotate=\pgfoovalueof{rotation angle},font=\huge]
{\pgfoovalueof{text}};
}
\method shift origin(#1,#2) { ... }
\method set rotation (#1) {
\pgfooset{rotation angle}{#1}
}
}
]],
documentation = "texmf:doc/generic/pgf/pgfmanual.pdf#pgf.back/attribute"
},
backgroundpath = {
arguments = {{meta = "code"}},
details = [[
This command specifies the path that "makes up" the background of the
shape. Note that the shape cannot prescribe what is going to happen with
the path: It might be drawn, shaded, filled, or even thrown away. If you
want to specify that something should "always" happen when this shape is
drawn (for example, if the shape is a stop-sign, we *always* want it to
be filled with a red color), you can use commands like
`\beforebackgroundpath`, explained below.
When the ⟨code⟩ is executed, all saved anchors will be in effect. The
⟨code⟩ should contain path construction commands.
For our `simple rectangle`, the following code might be used:
\backgroundpath{
\pgfpathrectanglecorners
{\upperrightcorner}
{\pgfpointscale{-1}{\upperrightcorner}}
}
As the name suggests, the background path is used "behind" the text
labels. Thus, this path is used first, then the text labels are drawn,
possibly obscuring part of the path.
]],
documentation = "texmf:doc/generic/pgf/pgfmanual.pdf#pgf.back/backgroundpath"
},
beforebackgroundpath = {
arguments = {{meta = "code"}},
details = [[
This command works like `\behindbackgroundpath`, only the ⟨code⟩ is
executed after the background path has been used, but before the texts
label are drawn.
]],
documentation = "texmf:doc/generic/pgf/pgfmanual.pdf#pgf.back/beforebackgroundpath"
},
beforedecoration = {
arguments = {{meta = "before code"}},
details = [[
Defines ⟨before code⟩ as (typically) PGF commands to be executed before
the decoration is applied to the current segment. This command can be
omitted. If you wish to set up some decoration specific parameters such
as segment length, or segment amplitude, then they can be set in ⟨before
code⟩.
]],
documentation = "texmf:doc/generic/pgf/pgfmanual.pdf#pgf.back/beforedecoration"
},
beforeforegroundpath = {
arguments = {{meta = "code"}},
details = [[
This ⟨code⟩ is executed at the very end.
]],
documentation = "texmf:doc/generic/pgf/pgfmanual.pdf#pgf.back/beforeforegroundpath"
},
behindbackgroundpath = {
arguments = {{meta = "code"}},
details = [[
Unlike the previous two commands, ⟨code⟩ should not only construct a
path, it should also use this path in whatever way is appropriate. For
example, the ⟨code⟩ might fill some area with a uniform color.
Whatever the ⟨code⟩ does, it does it first. This means that any drawing
done by ⟨code⟩ will be even behind the background path.
Note that the ⟨code⟩ is protected with a `{pgfscope}`.
]],
documentation = "texmf:doc/generic/pgf/pgfmanual.pdf#pgf.back/behindbackgroundpath"
},
behindforegroundpath = {
arguments = {{meta = "code"}},
details = [[
The ⟨code⟩ is executed after the text labels have been drawn, but before
the foreground path is used.
]],
documentation = "texmf:doc/generic/pgf/pgfmanual.pdf#pgf.back/behindforegroundpath"
},
breakforeach = {
details = [[
If this command is given inside a `\foreach` command, no further
executions of the ⟨commands⟩ will occur. However, the current execution
of the ⟨commands⟩ is continued normally, so it is probably best to use
this command only at the end of a `\foreach` command.
\begin{tikzpicture}
\foreach \x in {1,...,4}
\foreach \y in {1,...,4}
{
\fill[red!50] (\x,\y) ellipse (3pt and 6pt);
\ifnum \x<\y
\breakforeach
\fi
}
\end{tikzpicture}
]],
documentation = "texmf:doc/generic/pgf/pgfmanual.pdf#pgf.back/breakforeach"
},
calendar = {
arguments = {{meta = "calendar specification"}, {literal = ";"}},
documentation = "texmf:doc/generic/pgf/pgfmanual.pdf#pgf.back/calendar"
},
chainin = {
arguments = {
{delimiters = {"(", ")"}, meta = "existing name"},
{
delimiters = {"[", "]"},
keys = "$ref:tikz#/keys/tikz",
meta = "options",
optional = true
}
},
documentation = "texmf:doc/generic/pgf/pgfmanual.pdf#pgf.back/chainin"
},
clip = {
action = "tikzpath",
arguments = {{delimiters = {"", ";"}, meta = "specification"}},
details = [[
This option causes all subsequent drawings to be clipped against the
current path and the size of subsequent paths will not be important for
the picture size. If you clip against a self-intersecting path, the
even-odd rule or the nonzero winding number rule is used to determine
whether a point is inside or outside the clipping region.
The clipping path is a graphic state parameter, so it will be reset at
the end of the current scope. Multiple clippings accumulate, that is,
clipping is always done against the intersection of all clipping areas
that have been specified inside the current scopes. The only way of
enlarging the clipping area is to end a `{scope}`.
\begin{tikzpicture}
\draw[clip] (0,0) circle (1cm);
\fill[red] (1,0) circle (1cm);
\end{tikzpicture}
It is usually a *very* good idea to apply the `clip` option only to the
first path command in a scope.
If you "only wish to clip" and do not wish to draw anything, you can use
the `\clip` command, which is a shorthand for `\path[clip]`.
\begin{tikzpicture}
\clip (0,0) circle (1cm);
\fill[red] (1,0) circle (1cm);
\end{tikzpicture}
To keep clipping local, use `{scope}` environments as in the following
example:
\begin{tikzpicture}
\draw (0,0) -- ( 0:1cm);
\draw (0,0) -- (10:1cm);
\draw (0,0) -- (20:1cm);
\draw (0,0) -- (30:1cm);
\begin{scope}[fill=red]
\fill[clip] (0.2,0.2) rectangle (0.5,0.5);
\draw (0,0) -- (40:1cm);
\draw (0,0) -- (50:1cm);
\draw (0,0) -- (60:1cm);
\end{scope}
\draw (0,0) -- (70:1cm);
\draw (0,0) -- (80:1cm);
\draw (0,0) -- (90:1cm);
\end{tikzpicture}
There is a slightly annoying catch: You cannot specify certain graphic
options for the command used for clipping. For example, in the above
code we could not have moved the `fill=red` to the `\fill` command. The
reasons for this have to do with the internals of the PDF specification.
You do not want to know the details. It is best simply not to specify
any options for these commands.
]],
documentation = "texmf:doc/generic/pgf/pgfmanual.pdf#pgf.back/clip",
summary = "Inside `{tikzpicture}` this is an abbreviation for `\\path[clip]`."
},
colorcurrentmixin = {
details = [[
Expands to the current accumulated mix-in. Each nesting of a
`colormixin` adds a mix-in to this list.
\begin{minipage}{\linewidth-6pt}\raggedright
\begin{colormixin}{75!white}
\colorcurrentmixin\ should be ``!75!white''\par
\begin{colormixin}{75!black}
\colorcurrentmixin\ should be ``!75!black!75!white''\par
\begin{colormixin}{50!white}
\colorcurrentmixin\ should be ``!50!white!75!black!75!white''\par
\end{colormixin}
\end{colormixin}
\end{colormixin}
\end{minipage}
]],
documentation = "texmf:doc/generic/pgf/pgfmanual.pdf#pgf.back/colorcurrentmixin"
},
coordinate = {
action = "tikzpath",
arguments = {{delimiters = {"", ";"}, meta = "specification"}},
details = [[
Inside `{tikzpicture}` this is an abbreviation for `\path coordinate`.
]],
documentation = "texmf:doc/generic/pgf/pgfmanual.pdf#pgf.back/coordinate"
},
datavisualization = {
action = "tikzpath",
arguments = {{delimiters = {"", ";"}, meta = "specification"}},
details = [[
This command is available only inside a `{tikzpicture}` environment.
The ⟨data visualization options⟩ are used to configure the data
visualization, that is, how the data is to be depicted. The options are
executed with the path prefix `/tikz/data visualization`. This means
that normal TikZ options like `thin` or `red` cannot be used here.
Rather, a large number of options specific to data visualizations are
available.
As a minimum, you should specify at least two options: First, you should
use an option that selects an axis system that is appropriate for your
plot. Typical possible keys are `school book axes` or `scientific axes`,
detailed information on them can be found in Section ??.
Second, you use an option to select *how* the data should be visualized.
This is done using a key like `visualize as line` which will, as the
name suggests, visualize the data by connecting data points in the plane
using a line. Similarly, `visualize as smooth cycle` will try to fit a
smooth cycle through the data points. Detailed information on possible
visualizers can be found in Section ??.
Following these options, the ⟨data specification⟩ is used to provide the
actual to-be-visualized data. The syntax is somewhat similar to commands
like `\path`: The ⟨data specification⟩ is a sequence of keywords
followed by local options and parameters, terminated with a semicolon.
(Indeed, like for the `\path` command, the ⟨data visualizers options⟩
need not be specified at the beginning, but additional option surrounded
by square brackets may be given anywhere inside the ⟨data
specification⟩.)
The different possible keywords inside the ⟨data specification⟩ are
explained in the following.
]],
documentation = "texmf:doc/generic/pgf/pgfmanual.pdf#pgf.back/datavisualization"
},
decoration = {
arguments = {{meta = "name"}},
details = [[
This sets the decoration for the current state to ⟨name⟩. If this
command is omitted, the `moveto` decoration will be used.
]],
documentation = "texmf:doc/generic/pgf/pgfmanual.pdf#pgf.back/decoration"
},
deferredanchor = {
arguments = {{meta = "name"}, {meta = "code"}},
details = [[
This command declares an anchor named ⟨name⟩. It works like `\anchor`.
However, unlike for anchors declared by `\anchor`, ⟨name⟩ will *not* be
expanded during the shape declaration (i.e. not during
`\pgfdeclareshape`). Rather, the ⟨name⟩ is expanded when the *node* is
actually used (with `\pgfnode` or more likely with `\node`). This may be
useful if the anchor name is context dependent (depending, for example,
on the value of a key).
\makeatletter
\def\foo{foo}
\pgfdeclareshape{simple shape}{%
\savedanchor{\center}{%
\pgfpointorigin}
\anchor{center}{\center}
\savedanchor{\anchorfoo}{%
\pgf@x=1cm
\pgf@y=0cm}
\deferredanchor{anchor \foo}{\anchorfoo}}
\begin{tikzpicture}
\node[simple shape] (Test1) at (0,0) {};
\fill (Test1.anchor foo) circle (2pt) node[below] {anchor foo anchor};
%
\def\foo{bar}
\node[simple shape] (Test2) at (2,2) {};
\fill (Test2.anchor bar) circle (2pt) node[below] {anchor bar anchor};
\end{tikzpicture}
]],
documentation = "texmf:doc/generic/pgf/pgfmanual.pdf#pgf.back/deferredanchor"
},
draw = {
action = "tikzpath",
arguments = {{delimiters = {"", ";"}, meta = "specification"}},
details = [[
Causes the path to be drawn. "Drawing" (also known as "stroking") can be
thought of as picking up a pen and moving it along the path, thereby
leaving "ink" on the canvas.
There are numerous parameters that influence how a line is drawn, like
the thickness or the dash pattern. These options are explained below.
If the optional ⟨color⟩ argument is given, drawing is done using the
given ⟨color⟩. This color can be different from the current filling
color, which allows you to draw and fill a path with different colors.
If no ⟨color⟩ argument is given, the last usage of the `color=` option
is used.
If the special color name `none` is given, this option causes drawing to
be "switched off". This is useful if a style has previously switched on
drawing and you locally wish to undo this effect.
Although this option is normally used on paths to indicate that the path
should be drawn, it also makes sense to use the option with a `{scope}`
or `{tikzpicture}` environment. However, this will *not* cause all paths
to be drawn. Instead, this just sets the ⟨color⟩ to be used for drawing
paths inside the environment.
\begin{tikzpicture}
\path[draw=red] (0,0) -- (1,1) -- (2,1) circle (10pt);
\end{tikzpicture}
]],
documentation = "texmf:doc/generic/pgf/pgfmanual.pdf#pgf.back/draw",
summary = "Inside `{tikzpicture}` this is an abbreviation for `\\path[draw]`."
},
fill = {
action = "tikzpath",
arguments = {{delimiters = {"", ";"}, meta = "specification"}},
details = [[
This option causes the path to be filled. All unclosed parts of the path
are first closed, if necessary. Then, the area enclosed by the path is
filled with the current filling color, which is either the last color
set using the general `color=` option or the optional color ⟨color⟩. For
self-intersection paths and for paths consisting of several closed
areas, the "enclosed area" is somewhat complicated to define and two
different definitions exist, namely the nonzero winding number rule and
the even odd rule, see the explanation of these options, below.
Just as for the `draw` option, setting ⟨color⟩ to `none` disables
filling locally.
\begin{tikzpicture}
\fill (0,0) -- (1,1) -- (2,1);
\fill (4,0) circle (.5cm) (4.5,0) circle (.5cm);
\fill[even odd rule] (6,0) circle (.5cm) (6.5,0) circle (.5cm);
\fill (8,0) -- (9,1) -- (10,0) circle (.5cm);
\end{tikzpicture}
If the `fill` option is used together with the `draw` option (either
because both are given as options or because a `\filldraw` command is
used), the path is filled *first*, then the path is drawn *second*. This
is especially useful if different colors are selected for drawing and
for filling. Even if the same color is used, there is a difference
between this command and a plain `fill`: A "filldrawn" area will be
slightly larger than a filled area because of the thickness of the
"pen".
\begin{tikzpicture}[fill=yellow!80!black,line width=5pt]
\filldraw (0,0) -- (1,1) -- (2,1);
\filldraw (4,0) circle (.5cm) (4.5,0) circle (.5cm);
\filldraw[even odd rule] (6,0) circle (.5cm) (6.5,0) circle (.5cm);
\filldraw (8,0) -- (9,1) -- (10,0) circle (.5cm);
\end{tikzpicture}
]],
documentation = "texmf:doc/generic/pgf/pgfmanual.pdf#pgf.back/fill",
summary = "Inside `{tikzpicture}` this is an abbreviation for `\\path[fill]`."
},
filldraw = {
action = "tikzpath",
arguments = {{delimiters = {"", ";"}, meta = "specification"}},
details = [[
Inside `{tikzpicture}` this is an abbreviation for `\path[fill,draw]`.
]],
documentation = "texmf:doc/generic/pgf/pgfmanual.pdf#pgf.back/filldraw"
},
foreach = {
arguments = {{literal = " "}, {meta = "variables"}, {literal = " "}},
documentation = "texmf:doc/generic/pgf/pgfmanual.pdf#pgf.back/foreach"
},
foregroundpath = {
arguments = {{meta = "code"}},
details = [[
This command works like `\backgroundpath`, only it is invoked after the
text labels have been drawn. This means that this path can possibly
obscure (part of) the text labels.
]],
documentation = "texmf:doc/generic/pgf/pgfmanual.pdf#pgf.back/foregroundpath"
},
graph = {
action = "tikzpath",
arguments = {{delimiters = {"", ";"}, meta = "specification"}},
details = [[
Inside a `{tikzpicture}` this is an abbreviation for `\path graph`.
]],
documentation = "texmf:doc/generic/pgf/pgfmanual.pdf#pgf.back/graph"
},
ifdate = {
arguments = {{meta = "tests"}, {meta = "code"}, {meta = "else code"}},
details = [[
\[ifdate\] This command has the same effect as calling
`\pgfcalendarifdate` for the current date.
]],
documentation = "texmf:doc/generic/pgf/pgfmanual.pdf#pgf.back/ifdate"
},
inheritanchor = {
arguments = {
{literal = "[from="},
{meta = "another shape name"},
{literal = "]"},
{meta = "name"}
},
details = [[
Inherits the code of one specific anchor named ⟨name⟩ from ⟨another
shape name⟩. Thus, unlike saved anchors, which must be inherited
collectively, normal anchors can and must be inherited individually.
]],
documentation = "texmf:doc/generic/pgf/pgfmanual.pdf#pgf.back/inheritanchor"
},
inheritanchorborder = {
arguments = {
{literal = "[from="},
{meta = "another shape name"},
{literal = "]"}
},
details = [[
Inherits the border anchor code from ⟨another shape name⟩.
]],
documentation = "texmf:doc/generic/pgf/pgfmanual.pdf#pgf.back/inheritanchorborder"
},
inheritbackgroundpath = {
arguments = {
{literal = "[from="},
{meta = "another shape name"},
{literal = "]"}
},
details = [[
Inherits the background path code from ⟨another shape name⟩.
]],
documentation = "texmf:doc/generic/pgf/pgfmanual.pdf#pgf.back/inheritbackgroundpath"
},
inheritbeforebackgroundpath = {
arguments = {
{literal = "[from="},
{meta = "another shape name"},
{literal = "]"}
},
details = [[
Inherits the before background path code from ⟨another shape name⟩.
]],
documentation = "texmf:doc/generic/pgf/pgfmanual.pdf#pgf.back/inheritbeforebackgroundpath"
},
inheritbeforeforegroundpath = {
arguments = {
{literal = "[from="},
{meta = "another shape name"},
{literal = "]"}
},
details = [[
Inherits the before foreground path code from ⟨another shape name⟩.
]],
documentation = "texmf:doc/generic/pgf/pgfmanual.pdf#pgf.back/inheritbeforeforegroundpath"
},
inheritbehindbackgroundpath = {
arguments = {
{literal = "[from="},
{meta = "another shape name"},
{literal = "]"}
},
details = [[
This command can be used to inherit the code used for the drawings
behind the background path from ⟨another shape name⟩.
]],
documentation = "texmf:doc/generic/pgf/pgfmanual.pdf#pgf.back/inheritbehindbackgroundpath"
},
inheritbehindforegroundpath = {
arguments = {
{literal = "[from="},
{meta = "another shape name"},
{literal = "]"}
},
details = [[
Inherits the behind foreground path code from ⟨another shape name⟩.
]],
documentation = "texmf:doc/generic/pgf/pgfmanual.pdf#pgf.back/inheritbehindforegroundpath"
},
inheritforegroundpath = {
arguments = {
{literal = "[from="},
{meta = "another shape name"},
{literal = "]"}
},
details = [[
Inherits the foreground path code from ⟨another shape name⟩.
]],
documentation = "texmf:doc/generic/pgf/pgfmanual.pdf#pgf.back/inheritforegroundpath"
},
inheritsavedanchors = {
arguments = {
{literal = "[from="},
{meta = "another shape name"},
{literal = "]"}
},
details = [[
This command allows you to inherit the code for saved anchors from
⟨another shape name⟩. The idea is that if you wish to create a new shape
that is just a small modification of a another shape, you can recycle
the code used for ⟨another shape name⟩.
The effect of this command is the same as if you had called
`\savedanchor` and `\saveddimen` for each saved anchor or saved
dimension declared in ⟨another shape name⟩. Thus, it is not possible to
"selectively" inherit only some saved anchors, you always have to
inherit all saved anchors from another shape. However, you can inherit
the saved anchors of more than one shape by calling this command several
times.
]],
documentation = "texmf:doc/generic/pgf/pgfmanual.pdf#pgf.back/inheritsavedanchors"
},
jobname = {
details = [[
The value of `\jobname` is one of `\tikzexternalrealjob` or
`\pgfactualjobname`, depending on the configuration. In short: if
auxiliary file support (`\label` and `\ref`) is activated,
`\jobname=\tikzexternalrealjob` (since that's the base file name of
auxiliary files).
]],
documentation = "texmf:doc/generic/pgf/pgfmanual.pdf#pgf.back/jobname"
},
matrix = {
action = "tikzpath",
arguments = {{delimiters = {"", ";"}, meta = "specification"}},
details = [[
This option can be passed to a `node` path command. It signals that the
node will contain a matrix.
\begin{tikzpicture}
\draw[help lines] (0,0) grid (4,2);
\node [matrix,fill=red!20,draw=blue,very thick] (my matrix) at (2,1)
{
\draw (0,0) circle (4mm); & \node[rotate=10] {Hello}; \\
\draw (0.2,0) circle (2mm); & \fill[red] (0,0) circle (3mm); \\
};
\draw [very thick,->] (0,0) |- (my matrix.west);
\end{tikzpicture}
The exact syntax of the matrix is explained in the course of this
section.
]],
documentation = "texmf:doc/generic/pgf/pgfmanual.pdf#pgf.back/matrix",
summary = "Inside `{tikzpicture}` this is an abbreviation for `\\path node[matrix]`."
},
method = {
arguments = {
{meta = "method name"},
{delimiters = {"(", ")"}, meta = "parameter list"},
{meta = "method body"}
},
details = [[
This macro, which is only defined inside a class definition, defines a
new method named ⟨method name⟩. Just like class names, method names can
contain spaces and other characters, so ⟨method names⟩ like
`put_ stamp_ here` or `put stamp here` are both legal.
Three method names are special: First, a method having either the same
name as the class or having the name `init` is called the *constructor*
of the class. There are (currently) no destructors; objects simply
become "undefined" at the end of the scope in which they have been
created. The other two methods are called `get id` and `get handle`,
which are always automatically defined and which you cannot redefine.
They are discussed in Section ??.
Overloading of methods by differing numbers of parameters is not
possible, that is, it is illegal to have two methods inside a single
class with the same name (despite possibly different parameter lists).
However, two different classes may contain a method with the same name,
that is, classes form namespaces for methods. Also, a class can
(re)implement a method from a superclass.
The ⟨method name⟩ must be followed by a ⟨parameter list⟩ in parentheses,
which must be present even when the ⟨parameter list⟩ is empty. The
⟨parameter list⟩ is actually a normal TeX parameter list that will be
matched against the parameters inside the parentheses upon method
invocation and, thus, could be something like `# 1# 2 foo # 3 bar.`, but
a list like `# 1,# 2,# 3` is more customary. By setting the parameter
list to just `# 1` and then calling, say, `\pgfkeys{# 1}` at the
beginning of a method, you can implement Objective-C-like named
parameters.
When a method is called, the ⟨body⟩ of the method will be executed. The
main difference to a normal macro is that while the ⟨body⟩ is executed,
a special macro called `\pgfoothis` is set up in such a way that it
references the object for which the method is executed.
]],
documentation = "texmf:doc/generic/pgf/pgfmanual.pdf#pgf.back/method"
},
n = {
arguments = {{meta = "number register"}},
details = [[
When this macro is used on the left-hand side of an `=`-sign in a let
operation, it has no effect and is just there for readability. When the
macro is used on the right-hand side of an `=`-sign or in the body of
the let operation, then it expands to the value stored in the ⟨number
register⟩. This will either be a dimensionless number like `2.0` or a
dimension like `5.6pt`.
For instance, if we say `let \n1={1pt+2pt}, \n2={1+2} in ...`, then
inside the `...` part the macro `\n1` will expand to `3pt` and `\n2`
expands to `3`.
]],
documentation = "texmf:doc/generic/pgf/pgfmanual.pdf#pgf.back/n"
},
node = {
action = "tikzpath",
arguments = {{delimiters = {"", ";"}, meta = "specification"}},
details = [[
Inside `{tikzpicture}` this is an abbreviation for `\path node`.
]],
documentation = "texmf:doc/generic/pgf/pgfmanual.pdf#pgf.back/node"
},
nodepart = {
arguments = {
{literal = "["},
{keys = "$ref:tikz#/keys/tikz", meta = "options"},
{literal = "]"},
{meta = "part name"}
},
details = [[
This command can only be used inside the ⟨text⟩ argument of a `node`
path operation. It works a little bit like a `\part` command in LaTeX.
It will stop the typesetting of whatever node part was typeset until now
and then start putting all following text into the node part named ⟨part
name⟩ -- until another `\partname` is encountered or until the node
⟨text⟩ ends. The ⟨options⟩ will be local to this part.
\begin{tikzpicture}
\node [circle split,draw,double,fill=red!20]
{
% No \nodepart has been used, yet. So, the following is put in the
% ``text'' node part by default.
$q_1$
\nodepart{lower} % Ok, end ``text'' part, start ``output'' part
$00$
}; % output part ended.
\end{tikzpicture}
You will have to lookup which parts are defined by a shape.
The following styles influences node parts:
]],
documentation = "texmf:doc/generic/pgf/pgfmanual.pdf#pgf.back/nodepart"
},
nodeparts = {
arguments = {{meta = "list of node parts"}},
details = [[
This command declares which parts make up nodes of this shape. A *node
part* is a (possibly empty) text label that is drawn when a node of the
shape is created.
By default, a shape has just one node part called `text`. However, there
can be several node parts. For example, the `circle split` shape has two
parts: the `text` part, which shows that the upper text, and a `lower`
part, which shows the lower text. For the `circle split` shape the
`\nodeparts` command was called with the argument `{text,lower}`.
When a multipart node is created, the text labels are drawn in the
sequences listed in the ⟨list of node parts⟩. For each node part, you
must have declared one anchor and the TeX-box of the part is placed at
this anchor. For a node part called `XYZ` the TeX-box
`\pgfnodepartXYZbox` is placed at anchor `XYZ`.
]],
documentation = "texmf:doc/generic/pgf/pgfmanual.pdf#pgf.back/nodeparts"
},
p = {
arguments = {{meta = "point register"}},
details = [[
When this macro is used on the left-hand side of an `=`-sign in a let
operation, it has no effect and is just there for readability. When the
macro is used on the right-hand side of an `=`-sign or in the body of
the let operation, then it expands to the $x$-part (measured in
TeX points) of the coordinate stored in the ⟨register⟩, followed, by a
comma, followed by the $y$-part.
For instance, if we say `let \p1=(1pt,1pt+2pt) in ...`, then inside the
`...` part the macro `\p1` will expand to exactly the seven characters
"1pt,3pt". This means that you when you write `(\p1)`, this expands to
`(1pt,3pt)`, which is presumably exactly what you intended.
]],
documentation = "texmf:doc/generic/pgf/pgfmanual.pdf#pgf.back/p"
},
path = {
action = "tikzpath",
arguments = {{delimiters = {"", ";"}, meta = "specification"}},
details = [[
This command is available only inside a `{tikzpicture}` environment.
The ⟨specification⟩ is a long stream of *path operations*. Most of these
path operations tell TikZ how the path is built. For example, when you
write `–(0,0)`, you use a *line-to operation* and it means "continue the
path from wherever you are to the origin".
At any point where TikZ expects a path operation, you can also give some
graphic options, which is a list of options in brackets, such as
`[rounded corners]`. These options can have different effects:
1. Some options take "immediate" effect and apply to all subsequent
path operations on the path. For example, the `rounded corners`
option will round all following corners, but not the corners
"before" and if the `sharp corners` is given later on the path (in a
new set of brackets), the rounding effect will end.
\tikz \draw (0,0) -- (1,1)
[rounded corners] -- (2,0) -- (3,1)
[sharp corners] -- (3,0) -- (2,1);
Another example are the transformation options, which also apply
only to subsequent coordinates.
2. The options that have immediate effect can be "scoped" by putting
part of a path in curly braces. For example, the above example could
also be written as follows:
\tikz \draw (0,0) -- (1,1)
{[rounded corners] -- (2,0) -- (3,1)}
-- (3,0) -- (2,1);
3. Some options only apply to the path as a whole. For example, the
`color=` option for determining the color used for, say, drawing the
path always applies to all parts of the path. If several different
colors are given for different parts of the path, only the last one
(on the outermost scope) "wins":
\tikz \draw (0,0) -- (1,1)
[color=red] -- (2,0) -- (3,1)
[color=blue] -- (3,0) -- (2,1);
Most options are of this type. In the above example, we would have
had to "split up" the path into several `\path` commands:
\tikz{\draw (0,0) -- (1,1);
\draw [color=red] (1,1) -- (2,0) -- (3,1);
\draw [color=blue] (3,1) -- (3,0) -- (2,1);}
By default, the `\path` command does "nothing" with the path, it just
"throws it away". Thus, if you write `\path(0,0)–(1,1);`, nothing is
drawn in your picture. The only effect is that the area occupied by the
picture is (possibly) enlarged so that the path fits inside the area. To
actually "do" something with the path, an option like `draw` or `fill`
must be given somewhere on the path. Commands like `\draw` do this
implicitly.
Finally, it is also possible to give *node specifications* on a path.
Such specifications can come at different locations, but they are always
allowed when a normal path operation could follow. A node specification
starts with `node`. Basically, the effect is to typeset the node's text
as normal TeX text and to place it at the "current location" on the
path. The details are explained in Section ??.
Note, however, that the nodes are *not* part of the path in any way.
Rather, after everything has been done with the path what is specified
by the path options (like filling and drawing the path due to a `fill`
and a `draw` option somewhere in the ⟨specification⟩), the nodes are
added in a post-processing step.
*Note:* When scanning for path operations TikZ expands tokens looking
for valid path operations. This however implies that these tokens has to
be fully expandable up to the point where it results in a valid path