diff options
Diffstat (limited to 'Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-tutorial-map.tex')
-rw-r--r-- | Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-tutorial-map.tex | 663 |
1 files changed, 316 insertions, 347 deletions
diff --git a/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-tutorial-map.tex b/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-tutorial-map.tex index 99a173f9e39..e3af1d3b5fe 100644 --- a/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-tutorial-map.tex +++ b/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-tutorial-map.tex @@ -10,110 +10,105 @@ \section{Tutorial: A Lecture Map for Johannes} -In this tutorial we explore the tree and mind map mechanisms of -\tikzname. - -Johannes is quite excited: For the first time he will be teaching a -course all by himself during the upcoming semester! Unfortunately, the -course is not on his favorite subject, which is of course Theoretical Immunology, -but on Complexity Theory, but as a young academic Johannes is not -likely to complain too loudly. In order to help the students get a -general overview of what is going to happen during the course as a -whole, he intends to draw some kind of tree or graph containing the -basic concepts. He got this idea from his old professor who seems to -be using these ``lecture maps'' with some success. Independently of -the success of these maps, Johannes thinks they look quite neat. +In this tutorial we explore the tree and mind map mechanisms of \tikzname. +Johannes is quite excited: For the first time he will be teaching a course all +by himself during the upcoming semester! Unfortunately, the course is not on +his favorite subject, which is of course Theoretical Immunology, but on +Complexity Theory, but as a young academic Johannes is not likely to complain +too loudly. In order to help the students get a general overview of what is +going to happen during the course as a whole, he intends to draw some kind of +tree or graph containing the basic concepts. He got this idea from his old +professor who seems to be using these ``lecture maps'' with some success. +Independently of the success of these maps, Johannes thinks they look quite +neat. \subsection{Problem Statement} Johannes wishes to create a lecture map with the following features: +% \begin{enumerate} -\item It should contain a tree or graph depicting the main concepts. -\item It should somehow visualize the different lectures that will be - taught. Note that the lectures are not necessarily the same as the - concepts since the graph may contain more concepts than will be - addressed in lectures and some concepts may be addressed during more - than one lecture. -\item The map should also contain a calendar showing when the - individual lectures will be given. -\item The aesthetical reasons, the whole map should have a visually - nice and information-rich background. + \item It should contain a tree or graph depicting the main concepts. + \item It should somehow visualize the different lectures that will be + taught. Note that the lectures are not necessarily the same as the + concepts since the graph may contain more concepts than will be + addressed in lectures and some concepts may be addressed during more + than one lecture. + \item The map should also contain a calendar showing when the individual + lectures will be given. + \item The aesthetical reasons, the whole map should have a visually nice + and information-rich background. \end{enumerate} -As always, Johannes will have to include the right libraries and -set up the environment. Johannes is going to use the -|mindmap| library and since he wishes to show a calendar, he will also need -the |calendar| library. In order to put something -on a background layer, it seems like a good idea to also include the +As always, Johannes will have to include the right libraries and set up the +environment. Johannes is going to use the |mindmap| library and since he wishes +to show a calendar, he will also need the |calendar| library. In order to put +something on a background layer, it seems like a good idea to also include the |backgrounds| library. \subsection{Introduction to Trees} -The first choice Johannes must make is whether he will organize the -concepts as a tree, with root concepts and concept branches and leaf -concepts, or as a general graph. The tree implicitly organizes the -concepts, while a graph is more flexible. Johannes decides to -compromise: Basically, the concepts will be organized as a -tree. However, he will selectively add connections between concepts -that are related, but which appear on different levels or branches of +The first choice Johannes must make is whether he will organize the concepts as +a tree, with root concepts and concept branches and leaf concepts, or as a +general graph. The tree implicitly organizes the concepts, while a graph is +more flexible. Johannes decides to compromise: Basically, the concepts will be +organized as a tree. However, he will selectively add connections between +concepts that are related, but which appear on different levels or branches of the tree. -Johannes starts with a tree-like list of concepts that he feels are -important in Computational Complexity: - +Johannes starts with a tree-like list of concepts that he feels are important +in Computational Complexity: +% \begin{itemize} -\item Computational Problems - \begin{itemize}\itemsep=0pt\parskip=0pt - \item Problem Measures - \item Problem Aspects - \item Problem Domains - \item Key Problems - \end{itemize} -\item Computational Models - \begin{itemize}\itemsep=0pt\parskip=0pt - \item Turing Machines - \item Random-Access Machines - \item Circuits - \item Binary Decision Diagrams - \item Oracle Machines - \item Programming in Logic - \end{itemize} -\item Measuring Complexity - \begin{itemize}\itemsep=0pt\parskip=0pt - \item Complexity Measures - \item Classifying Complexity - \item Comparing Complexity - \item Describing Complexity - \end{itemize} -\item Solving Problems - \begin{itemize}\itemsep=0pt\parskip=0pt - \item Exact Algorithms - \item Randomization - \item Fixed-Parameter Algorithms - \item Parallel Computation - \item Partial Solutions - \item Approximation - \end{itemize} + \item Computational Problems + \begin{itemize}\itemsep=0pt\parskip=0pt + \item Problem Measures + \item Problem Aspects + \item Problem Domains + \item Key Problems + \end{itemize} + \item Computational Models + \begin{itemize}\itemsep=0pt\parskip=0pt + \item Turing Machines + \item Random-Access Machines + \item Circuits + \item Binary Decision Diagrams + \item Oracle Machines + \item Programming in Logic + \end{itemize} + \item Measuring Complexity + \begin{itemize}\itemsep=0pt\parskip=0pt + \item Complexity Measures + \item Classifying Complexity + \item Comparing Complexity + \item Describing Complexity + \end{itemize} + \item Solving Problems + \begin{itemize}\itemsep=0pt\parskip=0pt + \item Exact Algorithms + \item Randomization + \item Fixed-Parameter Algorithms + \item Parallel Computation + \item Partial Solutions + \item Approximation + \end{itemize} \end{itemize} -Johannes will surely need to modify this list later on, but it looks -good as a first approximation. He will also need to add a number of -subtopics (like \emph{lots} of complexity classes under the topic -``classifying complexity''), but he will do this as he constructs the -map. - -Turning the list of topics into a \tikzname-tree is easy, in -principle. The basic idea is that a node can have \emph{children}, -which in turn can have children of their own, and so on. To add a -child to a node, Johannes can simply write |child {|\meta{node}|}| -right after a node. The \meta{node} should, in turn, be the code for -creating a node. To add another node, Johannes can use |child| once -more, and so on. Johannes is eager to try out this construct and +Johannes will surely need to modify this list later on, but it looks good as a +first approximation. He will also need to add a number of subtopics (like +\emph{lots} of complexity classes under the topic ``classifying complexity''), +but he will do this as he constructs the map. + +Turning the list of topics into a \tikzname-tree is easy, in principle. The +basic idea is that a node can have \emph{children}, which in turn can have +children of their own, and so on. To add a child to a node, Johannes can simply +write |child {|\meta{node}|}| right after a node. The \meta{node} should, in +turn, be the code for creating a node. To add another node, Johannes can use +|child| once more, and so on. Johannes is eager to try out this construct and writes down the following: - +% \begin{codeexample}[] \tikz \node {Computational Complexity} % root @@ -147,27 +142,28 @@ writes down the following: }; \end{codeexample} -Well, that did not quite work out as expected (although, what, -exactly, did one expect?). There are two problems: +Well, that did not quite work out as expected (although, what, exactly, did one +expect?). There are two problems: +% \begin{enumerate} -\item The overlap of the nodes is due to the fact that \tikzname\ is - not particularly smart when it comes to placing child nodes. Even - though it is possible to configure \tikzname\ to use rather clever - placement methods, \tikzname\ has no way of taking the actual size - of the child nodes into account. This may seem strange but the - reason is that the child nodes are rendered and placed one at a - time, so the size of the last node is not known when the first node - is being processed. In essence, you have to specify appropriate - level and sibling node spacings ``by hand.'' -\item The standard computer-science-top-down rendering of a tree is - rather ill-suited to visualizing the concepts. It would be better to - either rotate the map by ninety degrees or, even better, to use some - sort of circular arrangement. + \item The overlap of the nodes is due to the fact that \tikzname\ is not + particularly smart when it comes to placing child nodes. Even though + it is possible to configure \tikzname\ to use rather clever placement + methods, \tikzname\ has no way of taking the actual size of the child + nodes into account. This may seem strange but the reason is that the + child nodes are rendered and placed one at a time, so the size of the + last node is not known when the first node is being processed. In + essence, you have to specify appropriate level and sibling node + spacings ``by hand''. + \item The standard computer-science-top-down rendering of a tree is + rather ill-suited to visualizing the concepts. It would be better to + either rotate the map by ninety degrees or, even better, to use some + sort of circular arrangement. \end{enumerate} -Johannes redraws the tree, but this time with some more appropriate -options set, which he found more or less by trial-and-error: - +Johannes redraws the tree, but this time with some more appropriate options +set, which he found more or less by trial-and-error: +% \begin{codeexample}[render instead={ \tikz [font=\footnotesize, grow=right, level 1/.style={sibling distance=6em}, @@ -202,37 +198,32 @@ options set, which he found more or less by trial-and-error: ... % as before \end{codeexample} -Still not quite what Johannes had in mind, but he is getting -somewhere. - -For configuring the tree, two parameters are of particular importance: -The |level distance| tells \tikzname\ the distance between (the -centers of) the nodes on adjacent levels or layers of a tree. The -|sibling distance| is, as the name suggests, the distance between (the -centers of) siblings of the tree. - -You can globally set these parameters for a tree by simply setting -them somewhere before the tree starts, but you will -typically wish them to be different for different levels of the -tree. In this case, you should set styles like |level 1| or -|level 2|. For the first level of the tree, the |level 1| style is -used, for the second level the |level 2| style, and so on. You can -also set the sibling and level distances only for certain nodes by -passing these options to the |child| command as options. (Note that -the options of a |node| command are local to the node and have no -effect on the children. Also note that it is possible to specify -options that do have an effect on the children. Finally note that -specifying options for children ``at the right place'' is an arcane -art and you should peruse Section~\ref{section-tree-options} on -a rainy Sunday afternoon, if you are really interested.) - -The |grow| key is used to configure the direction in which a tree -grows. You can change growth direction ``in the middle of a tree'' -simply by changing this key for a single child or a whole level. By -including the |trees| library you also get access to additional growth -strategies such as a ``circular'' growth: - - +Still not quite what Johannes had in mind, but he is getting somewhere. + +For configuring the tree, two parameters are of particular importance: The +|level distance| tells \tikzname\ the distance between (the centers of) the +nodes on adjacent levels or layers of a tree. The |sibling distance| is, as the +name suggests, the distance between (the centers of) siblings of the tree. + +You can globally set these parameters for a tree by simply setting them +somewhere before the tree starts, but you will typically wish them to be +different for different levels of the tree. In this case, you should set styles +like |level 1| or |level 2|. For the first level of the tree, the |level 1| +style is used, for the second level the |level 2| style, and so on. You can +also set the sibling and level distances only for certain nodes by passing +these options to the |child| command as options. (Note that the options of a +|node| command are local to the node and have no effect on the children. Also +note that it is possible to specify options that do have an effect on the +children. Finally note that specifying options for children ``at the right +place'' is an arcane art and you should peruse +Section~\ref{section-tree-options} on a rainy Sunday afternoon, if you are +really interested.) + +The |grow| key is used to configure the direction in which a tree grows. You +can change growth direction ``in the middle of a tree'' simply by changing this +key for a single child or a whole level. By including the |trees| library you +also get access to additional growth strategies such as a ``circular'' growth: +% \begin{codeexample}[render instead={ \tikz [text width=2.7cm, align=flush center, grow cyclic, @@ -269,42 +260,38 @@ strategies such as a ``circular'' growth: ... % as before \end{codeexample} - -Johannes is pleased to learn that he can access and manipulate the -nodes of the tree like any normal node. In particular, he can name them -using the |name=| option or the |(|\meta{name}|)| notation and he can -use any available shape or style for the trees nodes. He can connect -trees later on using the normal |\draw (some node) -- (another node);| -syntax. In essence, the |child| command just computes an appropriate -position for a node and adds a line from the child to the parent -node. +Johannes is pleased to learn that he can access and manipulate the nodes of the +tree like any normal node. In particular, he can name them using the |name=| +option or the |(|\meta{name}|)| notation and he can use any available shape or +style for the trees nodes. He can connect trees later on using the normal +|\draw (some node) -- (another node);| syntax. In essence, the |child| command +just computes an appropriate position for a node and adds a line from the child +to the parent node. \subsection{Creating the Lecture Map} -Johannes now has a first possible layout for his lecture map. The next -step is to make it ``look nicer.'' For this, the |mindmap| library is -helpful since it makes a number of styles available that will make a -tree look like a nice ``mind map'' or ``concept map.'' - -The first step is to include the |mindmap| library, which Johannes -already did. Next, he must add one of the following options to a scope -that will contain the lecture map: |mindmap| or |large mindmap| or -|huge mindmap|. These options all have the same effect, except that -for a |large mindmap| the predefined font size and node sizes are -somewhat larger than for a standard |mindmap| and for a |huge mindmap| -they are even larger. So, a |large mindmap| does not necessarily need -to have a lot of concepts, but it will need a lot of paper. - -The second step is to add the |concept| option to every node that -will, indeed, be a concept of the mindmap. The idea is that some nodes -of a tree will be real concepts, while other nodes might just be -``simple children.'' Typically, this is not the case, so you might -consider saying |every node/.style=concept|. - -The third step is to set up the sibling \emph{angle} (rather than a -sibling distance) to specify the angle between sibling concepts. - +Johannes now has a first possible layout for his lecture map. The next step is +to make it ``look nicer''. For this, the |mindmap| library is helpful since it +makes a number of styles available that will make a tree look like a nice +``mind map'' or ``concept map''. + +The first step is to include the |mindmap| library, which Johannes already did. +Next, he must add one of the following options to a scope that will contain the +lecture map: |mindmap| or |large mindmap| or |huge mindmap|. These options all +have the same effect, except that for a |large mindmap| the predefined font +size and node sizes are somewhat larger than for a standard |mindmap| and for a +|huge mindmap| they are even larger. So, a |large mindmap| does not necessarily +need to have a lot of concepts, but it will need a lot of paper. + +The second step is to add the |concept| option to every node that will, indeed, +be a concept of the mindmap. The idea is that some nodes of a tree will be real +concepts, while other nodes might just be ``simple children''. Typically, this +is not the case, so you might consider saying |every node/.style=concept|. + +The third step is to set up the sibling \emph{angle} (rather than a sibling +distance) to specify the angle between sibling concepts. +% \begin{codeexample}[render instead={ \tikz [mindmap, every node/.style=concept, concept color=black!20, grow cyclic, @@ -350,21 +337,19 @@ sibling distance) to specify the angle between sibling concepts. ... % as before \end{codeexample} -When Johannes typesets the above map, \TeX\ (rightfully) starts -complaining about several overfull boxes and, indeed, words like -``Randomization'' stretch out beyond the circle of the concept. This -seems a bit mysterious at first sight: Why does \TeX\ not hyphenate -the word? The reason is that \TeX\ will never hyphenate the first word -of a paragraph because it starts looking for ``hyphenatable'' letters -only after a so-called glue. In order to have \TeX\ hyphenate these -single words, Johannes must use a bit of evil trickery: He inserts a -|\hskip0pt| before the word. This has no effect except for inserting -an (invisible) glue before the word and, thereby, allowing \TeX\ to -hyphenate the first word also. Since Johannes does not want to add -|\hskip0pt| inside each node, he uses the |execute at begin node| -option to make \tikzname\ insert this text with every node. - - +When Johannes typesets the above map, \TeX\ (rightfully) starts complaining +about several overfull boxes and, indeed, words like ``Randomization'' stretch +out beyond the circle of the concept. This seems a bit mysterious at first +sight: Why does \TeX\ not hyphenate the word? The reason is that \TeX\ will +never hyphenate the first word of a paragraph because it starts looking for +``hyphenatable'' letters only after a so-called glue. In order to have \TeX\ +hyphenate these single words, Johannes must use a bit of evil trickery: He +inserts a |\hskip0pt| before the word. This has no effect except for inserting +an (invisible) glue before the word and, thereby, allowing \TeX\ to hyphenate +the first word also. Since Johannes does not want to add |\hskip0pt| inside +each node, he uses the |execute at begin node| option to make \tikzname\ insert +this text with every node. +% \begin{codeexample}[render instead={ \begin{tikzpicture} [mindmap, @@ -421,37 +406,34 @@ option to make \tikzname\ insert this text with every node. \end{tikzpicture} \end{codeexample} - -In the above example a clipping was used to show only part of the -lecture map, in order to save space. The same will be done in the -following examples, we return to the complete lecture map at the end of this -tutorial. - -Johannes is now eager to colorize the map. The idea is to use -different colors for different parts of the map. He can then, during -his lectures, talk about the ``green'' or the ``red'' topics. This -will make it easier for his students to locate the topic he is talking -about on the map. Since ``computational problems'' somehow sounds -``problematic,'' Johannes chooses red for them, while he picks green -for the ``solving problems.'' The topics ``measuring complexity'' and -``computational models'' get more neutral colors; Johannes picks -orange and blue. - -To set the colors, Johannes must use the |concept color| option, -rather than just, say, |node [fill=red]|. Setting just the fill color -to |red| would, indeed, make the node red, but it would \emph{just} -make the node red and not the bar connecting the concept to its parent -and also not its children. By comparison, the special |concept color| -option will not only set the color of the node and its children, but -it will also (magically) create appropriate shadings so that the color -of a parent concept smoothly changes to the color of a child concept. - -For the root concept Johannes decides to do something special: He sets -the concept color to black, sets the line width to a large value, and -sets the fill color to white. The effect of this is that the root -concept will be encircled with a thick black line and the children are -connected to the central concept via bars. - +In the above example a clipping was used to show only part of the lecture map, +in order to save space. The same will be done in the following examples, we +return to the complete lecture map at the end of this tutorial. + +Johannes is now eager to colorize the map. The idea is to use different colors +for different parts of the map. He can then, during his lectures, talk about +the ``green'' or the ``red'' topics. This will make it easier for his students +to locate the topic he is talking about on the map. Since ``computational +problems'' somehow sounds ``problematic'', Johannes chooses red for them, while +he picks green for the ``solving problems''. The topics ``measuring +complexity'' and ``computational models'' get more neutral colors; Johannes +picks orange and blue. + +To set the colors, Johannes must use the |concept color| option, rather than +just, say, |node [fill=red]|. Setting just the fill color to |red| would, +indeed, make the node red, but it would \emph{just} make the node red and not +the bar connecting the concept to its parent and also not its children. By +comparison, the special |concept color| option will not only set the color of +the node and its children, but it will also (magically) create appropriate +shadings so that the color of a parent concept smoothly changes to the color of +a child concept. + +For the root concept Johannes decides to do something special: He sets the +concept color to black, sets the line width to a large value, and sets the fill +color to white. The effect of this is that the root concept will be encircled +with a thick black line and the children are connected to the central concept +via bars. +% \begin{codeexample}[render instead={ \begin{tikzpicture} [mindmap, @@ -525,17 +507,16 @@ connected to the central concept via bars. \end{tikzpicture} \end{codeexample} -Johannes adds three finishing touches: First, he changes the font -of the main concepts to small caps. Second, he decides that some -concepts should be ``faded,'' namely those that are important in -principle and belong on the map, but which he will not talk about in -his lecture. To achieve this, Johannes defines four styles, one for -each of the four main branches. These styles (a) set up the -correct concept color for the whole branch and (b) define the |faded| -style appropriately for this branch. Third, he adds a -|circular drop shadow|, defined in the |shadows| library, to the -concepts, just to make things look a bit more fancy. - +Johannes adds three finishing touches: First, he changes the font of the main +concepts to small caps. Second, he decides that some concepts should be +``faded'', namely those that are important in principle and belong on the map, +but which he will not talk about in his lecture. To achieve this, Johannes +defines four styles, one for each of the four main branches. These styles (a) +set up the correct concept color for the whole branch and (b) define the +|faded| style appropriately for this branch. Third, he adds a +|circular drop shadow|, defined in the |shadows| library, to the concepts, just +to make things look a bit more fancy. +% \begin{codeexample}[render instead={ \begin{tikzpicture}[mindmap] \begin{scope}[ @@ -614,25 +595,22 @@ concepts, just to make things look a bit more fancy. \subsection{Adding the Lecture Annotations} -Johannes will give about a dozen lectures during the course -``computational complexity.'' For each lecture he has compiled a -(short) list of learning targets that state what knowledge and -qualifications his students should acquire during this particular -lecture (note that learning targets are not the same as the contents -of a lecture). For each lecture he intends to put a little rectangle -on the map containing these learning targets and the name of the -lecture, each time somewhere near the topic of the lecture. Such -``little rectangles'' are called ``annotations'' by the mindmap -library. - -In order to place the annotations next to the concepts, Johannes must -assign names to the nodes of the concepts. He could rely on -\tikzname's automatic naming of the nodes in a tree, where the -children of a node named |root| are named |root-1|, |root-2|, -|root-3|, and so on. However, since Johannes is not sure about the -final order of the concepts in the tree, it seems better to explicitly -name all concepts of the tree in the following manner: - +Johannes will give about a dozen lectures during the course ``computational +complexity''. For each lecture he has compiled a (short) list of learning +targets that state what knowledge and qualifications his students should +acquire during this particular lecture (note that learning targets are not the +same as the contents of a lecture). For each lecture he intends to put a little +rectangle on the map containing these learning targets and the name of the +lecture, each time somewhere near the topic of the lecture. Such ``little +rectangles'' are called ``annotations'' by the mindmap library. + +In order to place the annotations next to the concepts, Johannes must assign +names to the nodes of the concepts. He could rely on \tikzname's automatic +naming of the nodes in a tree, where the children of a node named |root| are +named |root-1|, |root-2|, |root-3|, and so on. However, since Johannes is not +sure about the final order of the concepts in the tree, it seems better to +explicitly name all concepts of the tree in the following manner: +% \begin{codeexample}[code only] \node [root concept] (Computational Complexity) {Computational Complexity} child [computational problems] { node (Computational Problems) {Computational Problems} @@ -644,10 +622,10 @@ name all concepts of the tree in the following manner: ... \end{codeexample} -The |annotation| style of the mind map library mainly sets up a -rectangular shape of appropriate size. Johannes configures the style -by defining |every annotation| appropriately. - +The |annotation| style of the mind map library mainly sets up a rectangular +shape of appropriate size. Johannes configures the style by defining +|every annotation| appropriately. +% \begin{codeexample}[render instead={ \begin{tikzpicture}[mindmap] \clip (-5.25,-3) rectangle ++ (4,5); @@ -726,21 +704,19 @@ by defining |every annotation| appropriately. \end{tikzpicture} \end{codeexample} -Well, that does not yet look quite perfect. The spacing or the -|{itemize}| is not really appropriate and the node is too -large. Johannes can configure these things ``by hand,'' but it seems -like a good idea to define a macro that will take care of these things -for him. The ``right'' way to do this is to define a |\lecture| macro -that takes a list of key-value pairs as argument and produces the -desired annotation. However, to keep things simple, Johannes' -|\lecture| macro simply takes a fixed number of arguments having the -following meaning: The first argument is the number of the lecture, -the second is the name of the lecture, the third are positioning -options like |above|, the fourth is the position where the node is -placed, the fifth is the list of items to be shown, and the sixth is a -date when the lecture will be held (this parameter is not yet needed, -we will, however, need it later on). - +Well, that does not yet look quite perfect. The spacing or the |{itemize}| is +not really appropriate and the node is too large. Johannes can configure these +things ``by hand'', but it seems like a good idea to define a macro that will +take care of these things for him. The ``right'' way to do this is to define a +|\lecture| macro that takes a list of key--value pairs as argument and produces +the desired annotation. However, to keep things simple, Johannes' |\lecture| +macro simply takes a fixed number of arguments having the following meaning: +The first argument is the number of the lecture, the second is the name of the +lecture, the third are positioning options like |above|, the fourth is the +position where the node is placed, the fifth is the list of items to be shown, +and the sixth is a date when the lecture will be held (this parameter is not +yet needed, we will, however, need it later on). +% \begin{codeexample}[code only] \def\lecture#1#2#3#4#5#6{ \node [annotation, #3, scale=0.65, text width=4cm, inner sep=2mm] at (#4) { @@ -833,40 +809,36 @@ we will, however, need it later on). \end{tikzpicture} \end{codeexample} -In the same fashion Johannes can now add the other lecture -annotations. Obviously, Johannes will have some trouble fitting -everything on a single A4-sized page, but by adjusting the spacing and -some experimentation he can quickly arrange all the annotations as needed. +In the same fashion Johannes can now add the other lecture annotations. +Obviously, Johannes will have some trouble fitting everything on a single +A4-sized page, but by adjusting the spacing and some experimentation he can +quickly arrange all the annotations as needed. \subsection{Adding the Background} -Johannes has already used colors to organize his lecture map into four -regions, each having a different color. In order to emphasize these -regions even more strongly, he wishes to add a background coloring to -each of these regions. - -Adding these background colors turns out to be more tricky than -Johannes would have thought. At first sight, what he needs is some -sort of ``color wheel'' that is blue in the lower right direction and -then changes smoothly to orange in the upper right direction and then -to green in the upper left direction and so on. Unfortunately, there -is no easy way of creating such a color wheel shading (although -it can be done, in principle, but only at a very high cost, see -page~\pageref{shading-color-wheel} for an example). - -Johannes decides to do something a bit more basic: He creates four -large rectangles, one for each of the four quadrants around the -central concept, each colored with a light version of the -quadrant. Then, in order to ``smooth'' the change between adjacent -rectangles, he puts four shadings on top of them. - -Since these background rectangles should go ``behind'' everything -else, Johannes puts all his background stuff on the |background| -layer. - -In the following code, only the central concept is shown to save some -space: +Johannes has already used colors to organize his lecture map into four regions, +each having a different color. In order to emphasize these regions even more +strongly, he wishes to add a background coloring to each of these regions. + +Adding these background colors turns out to be more tricky than Johannes would +have thought. At first sight, what he needs is some sort of ``color wheel'' +that is blue in the lower right direction and then changes smoothly to orange +in the upper right direction and then to green in the upper left direction and +so on. Unfortunately, there is no easy way of creating such a color wheel +shading (although it can be done, in principle, but only at a very high cost, +see page~\pageref{shading-color-wheel} for an example). + +Johannes decides to do something a bit more basic: He creates four large +rectangles, one for each of the four quadrants around the central concept, each +colored with a light version of the quadrant. Then, in order to ``smooth'' the +change between adjacent rectangles, he puts four shadings on top of them. + +Since these background rectangles should go ``behind'' everything else, +Johannes puts all his background stuff on the |background| layer. + +In the following code, only the central concept is shown to save some space: +% \begin{codeexample}[] \begin{tikzpicture}[ mindmap, @@ -910,29 +882,26 @@ space: \end{codeexample} - \subsection{Adding the Calendar} -Johannes intends to plan his lecture rather carefully. In particular, -he already knows when each of his lectures will be held during the -course. Naturally, this does not mean that Johannes will slavishly -follow the plan and he might need longer for some subjects than he -anticipated, but nevertheless he has a detailed plan of when which -subject will be addressed. - -Johannes intends to share this plan with his students by adding a -calendar to the lecture map. In addition to serving as a reference -on which particular day a certain topic will be addressed, the -calendar is also useful to show the overall chronological order of the -course. - -In order to add a calendar to a \tikzname\ graphic, the |calendar| -library is most useful. The library provides the |\calendar| command, -which takes a large number of options and which can be configured in -many ways to produce just about any kind of calendar imaginable. For -Johannes' purposes, a simple |day list downward| will be a nice option -since it produces a list of days that go ``downward''. - +Johannes intends to plan his lecture rather carefully. In particular, he +already knows when each of his lectures will be held during the course. +Naturally, this does not mean that Johannes will slavishly follow the plan and +he might need longer for some subjects than he anticipated, but nevertheless he +has a detailed plan of when which subject will be addressed. + +Johannes intends to share this plan with his students by adding a calendar to +the lecture map. In addition to serving as a reference on which particular day +a certain topic will be addressed, the calendar is also useful to show the +overall chronological order of the course. + +In order to add a calendar to a \tikzname\ graphic, the |calendar| library is +most useful. The library provides the |\calendar| command, which takes a large +number of options and which can be configured in many ways to produce just +about any kind of calendar imaginable. For Johannes' purposes, a simple +|day list downward| will be a nice option since it produces a list of days that +go ``downward''. +% \begin{codeexample}[leave comments] \tiny \begin{tikzpicture} @@ -944,29 +913,26 @@ since it produces a list of days that go ``downward''. \end{tikzpicture} \end{codeexample} -Using the |name| option, we gave a name to the calendar, which will -allow us to reference the nodes that make up the individual days of -the calendar later on. For instance, the rectangular node containing the -|1| that represents April 1st, 2009, can be referenced as -|(cal-2009-04-01)|. The |dates| option is used to specify an -interval for which the calendar should be drawn. Johannes will need -several months in his calendar, but the above example only shows two -weeks to save some space. - -Note the |if (weekend)| construct. The |\calendar| command is followed -by options and then by |if|-statements. These |if|-statements are -checked for each day of the calendar and when a date passes this test, -the options or the code following the |if|-statement is executed. In -the above example, we make weekend days (Saturdays and Sundays, to be -precise) lighter than normal days. (Use your favorite calendar to -check that, indeed, April 5th, 2009, is a Sunday.) - -As mentioned above, Johannes can reference the nodes that are used to -typeset days. Recall that his |\lecture| macro already got passed a -date, which we did not use, yet. We can now use it to place the -lecture's title next to the date when the lecture will be held: - - +Using the |name| option, we gave a name to the calendar, which will allow us to +reference the nodes that make up the individual days of the calendar later on. +For instance, the rectangular node containing the |1| that represents April +1st, 2009, can be referenced as |(cal-2009-04-01)|. The |dates| option is used +to specify an interval for which the calendar should be drawn. Johannes will +need several months in his calendar, but the above example only shows two weeks +to save some space. + +Note the |if (weekend)| construct. The |\calendar| command is followed by +options and then by |if|-statements. These |if|-statements are checked for each +day of the calendar and when a date passes this test, the options or the code +following the |if|-statement is executed. In the above example, we make weekend +days (Saturdays and Sundays, to be precise) lighter than normal days. (Use your +favorite calendar to check that, indeed, April 5th, 2009, is a Sunday.) + +As mentioned above, Johannes can reference the nodes that are used to typeset +days. Recall that his |\lecture| macro already got passed a date, which we did +not use, yet. We can now use it to place the lecture's title next to the date +when the lecture will be held: +% \begin{codeexample}[code only] \def\lecture#1#2#3#4#5#6{ % As before: @@ -986,9 +952,9 @@ lecture's title next to the date when the lecture will be held: \node [anchor=base west] at (cal-#6.base east) {\textcolor{orange}{\textbf{#2}}}; } -Johannes can now use this new |\lecture| command as follows (in the -example, only the new part of the definition is used): - +Johannes can now use this new |\lecture| command as follows (in the example, +only the new part of the definition is used): +% \begin{codeexample}[] \tiny \begin{tikzpicture} @@ -1008,13 +974,11 @@ example, only the new part of the definition is used): \end{tikzpicture} \end{codeexample} - -As a final step, Johannes needs to add a few more options to the -calendar command: He uses the |month text| option to configure how the -text of a month is rendered (see Section~\ref{section-calender} for -details) and then typesets the month text at a special position at the -beginning of each month. - +As a final step, Johannes needs to add a few more options to the calendar +command: He uses the |month text| option to configure how the text of a month +is rendered (see Section~\ref{section-calender} for details) and then typesets +the month text at a special position at the beginning of each month. +% \begin{codeexample}[leave comments] \tiny \begin{tikzpicture} @@ -1046,13 +1010,12 @@ beginning of each month. \end{codeexample} - \subsection{The Complete Code} Putting it all together, Johannes gets the following code: First comes the definition of the |\lecture| command: - +% \begin{codeexample}[code only] \def\lecture#1#2#3#4#5#6{ % As before: @@ -1070,7 +1033,7 @@ First comes the definition of the |\lecture| command: \end{codeexample} This is followed by the main mindmap setup\dots - +% \begin{codeexample}[code only] \noindent \begin{tikzpicture} @@ -1123,7 +1086,9 @@ This is followed by the main mindmap setup\dots }; \end{scope} \end{codeexample} +% Now comes the calendar code: +% \begin{codeexample}[code only] \tiny \calendar [day list downward, @@ -1138,7 +1103,9 @@ Now comes the calendar code: \node at (0pt,1.5em) [anchor=base west] {\small\tikzmonthtext}; }; \end{codeexample} +% The lecture annotations: +% \begin{codeexample}[code only] \lecture{1}{Computational Problems}{above,xshift=-5mm,yshift=5mm}{Computational Problems.north}{ \item Knowledge of several key problems @@ -1153,7 +1120,9 @@ The lecture annotations: models }{2009-04-15} \end{codeexample} +% Finally, the background: +% \begin{codeexample}[code only] \begin{pgfonlayer}{background} \clip[xshift=-1cm] (-.5\textwidth,-.5\textheight) rectangle ++(\textwidth,\textheight); |