summaryrefslogtreecommitdiff
path: root/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-tutorial-map.tex
diff options
context:
space:
mode:
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.tex663
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);