summaryrefslogtreecommitdiff
path: root/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-tikz-design.tex
diff options
context:
space:
mode:
Diffstat (limited to 'Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-tikz-design.tex')
-rw-r--r--Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-tikz-design.tex36
1 files changed, 20 insertions, 16 deletions
diff --git a/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-tikz-design.tex b/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-tikz-design.tex
index 5f8060625dc..1ecb8efa5f3 100644
--- a/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-tikz-design.tex
+++ b/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-tikz-design.tex
@@ -22,8 +22,8 @@ sources. The basic command names and the notion of path operations is
taken from \textsc{metafont}, the option mechanism comes from
\textsc{pstricks}, the notion of styles is reminiscent of
\textsc{svg}. To make it all work together, some compromises were
-necessary. I also added some ideas of my own, like meta-arrows and
-coordinate transformations.
+necessary. I also added some ideas of my own, like coordinate
+transformations.
The following basic design principles underlie \tikzname:
\begin{enumerate}
@@ -116,6 +116,7 @@ environments.
stroking.
\subsection{Key-Value Syntax for Graphic Parameters}
+
Whenever \tikzname\ draws or fills a path, a large number of graphic
parameters influenced the rendering. Examples include the colors
used, the dashing pattern, the clipping area, the line width, and
@@ -174,9 +175,10 @@ modify the way trees are drawn. Here are two examples of the above tree,
redrawn with different options:
\begin{codeexample}[]
-\begin{tikzpicture}[edge from parent fork down]
- \tikzstyle{every node}=[fill=red!30,rounded corners]
- \tikzstyle{edge from parent}=[red,-o,thick,draw]
+\begin{tikzpicture}
+ [edge from parent fork down,
+ every node/.style={fill=red!30,rounded corners},
+ edge from parent/.style={red,-o,thick,draw}]
\node {root}
child {node {left}}
child {node {right}
@@ -188,9 +190,9 @@ redrawn with different options:
\begin{codeexample}[]
\begin{tikzpicture}
- [parent anchor=east,child anchor=west,grow=east]
- \tikzstyle{every node}=[ball color=red,circle,text=white]
- \tikzstyle{edge from parent}=[draw,dashed,thick,red]
+ [parent anchor=east,child anchor=west,grow=east,
+ every node/.style={ball color=red,circle,text=white}
+ edge from parent/.style={draw,dashed,thick,red}]
\node {root}
child {node {left}}
child {node {right}
@@ -236,15 +238,17 @@ the picture.
\subsection{Coordinate Transformation System}
-\tikzname\ relies entirely on \pgfname's \emph{coordinate} transformation
-system to perform transformations. \pgfname\ also supports
-\emph{canvas} transformations, a more low-level transformation system,
-but this system is not accessible from \tikzname. There are two reasons
+\tikzname\ supports both \pgfname's \emph{coordinate} transformation
+system to perform transformations as well as \emph{canvas}
+transformations, a more low-level transformation system. (For
+details on the difference between coordinate transformations and
+canvas transformations see Section~\ref{section-design-transformations}.)
+
+The syntax is setup in such a way that is harder to use canvas
+transformations than coordinate transformations. There are two reasons
for this: First, the canvas transformation must be used with great
care and often results in ``bad'' graphics with changing line width
and text in wrong sizes. Second, \pgfname\ looses track of where nodes
and shapes are positioned when canvas transformations are used.
-
-For more details on the difference between coordinate transformations
-and canvas transformations see
-Section~\ref{section-design-transformations}.
+So, in almost all circumstances, you should use coordinate
+transformations rather than canvas transformations.