arc

Der arc-Path-Operator von TikZ ist bekanntermaßen etwas unflexibel, da er – abgesehen von den Radien – nur mit Start-, End- und Delta-Winkeln etwas anfangen kann.

\pgfpatharcto

PGF selbst bietet da noch etwas mehr, hier passt das Macro \pgfpatharcto, das im PGF manual auf Seite 892 geklärt wird. Neben den Radien (#1, #2) benötigt man noch die Rotation #3 sowie zwei Flags (#4, #5) und den Zielpunkt #6. Die Rotation ist nur relevant, falls man unterschiedliche Radien verwendet (nicht am Rad drehen ;)).

Flags und Rotation

Die Flags sind aber selbst im einfachen Fall relevant, da man für einen gegeben Radius vier Kreisbögen konstruieren kann, die an einem Punkt starten und an einem anderen Punkt enden, nämlich linksrum/rechtsrum (das ist der counterclockwise flag, #5) und innenrum/außenrum (large arc flac, #4). Da TikZ mathematisch positiv immer gegen den Uhrzeigersinn rechnet, habe ich dementsprechend auch den Key arc ccw mit 1 initialisiert; da man vermutlich eher an den inneren Kreisbogen denkt, wird arc large mit 0 initialisiert.

Ungenauigkeit

Eine kleine Warnung, die ich aus dem Manual zitieren möchte, vorweg (Überstzung von mir):

Warning: The internal computations necessary for this command are numerically very unstable. In particular, the arc will not always really end at the <target coordinate>, but may be off by up to several points. A more precise positioning is currently infeasible due to TeX’s numerical weaknesses. The only case it works quite nicely is when the resulting angle is a multiple of 90°.

---

Achtung: Die internen Berechnungen, die für diesen Befehl nötig sind, sind numerisch instabil. Im Besonderen wird der Bogen nicht immer wirklich am spezifierten Endpunkt enden, sondern um einige Punkte daneben liegen. Eine präzisere Positionierung ist derzeit aufgrund TeX’s numerischer Schwäche nicht erreichbar. Der einzige Fall, bei dem das sehr gut funktioniert, ist, wenn der Winkel ein Vielfaches von 90 Grad ist.

Implementation

Beachte auch bitte meine Implementierung eher als Proof-of-Concept.

Ich habe mich dazu entschlossen, nicht den bereits vorhandenen arc-Path-Operator neu zu definieren, weil der Code dann auch noch unterscheiden muss zwischen dem klassichen Bogen mit den * angle-Optionen und dem hier benutzten. (Ja, theoretisch sind natürlich Kombination wie „der Startwinkel, der Radius und der Endpunkt”, aber das kann eben keiner von beiden ausrechnen.)

Es ist quasi ein komplett unabhängiger Path-Operator, der statt arc eben arc to heißt (arcto ginge auch); er verwendet eben falls die Keys radius, x radius und y radius sowie den eventuell definierten every arc-Style.

Nodes als Ziel

Falls man eine Node als Endpunkt auswählt und von dort eine Linie weiter zeichnen will, also zum Beispiel

\node (B) {Bogen-Ziel};
\draw (a) arc to[] (B) -- (a);

startet die Linie nicht am Zentrum von B (wo der Bogen endet), sondern dort wo er auch bei (B) -- (a) starten würde. Dies ist durch die Zeilen

\iftikz@shapeborder
  \edef\tikz@moveto@waiting{\tikz@shapeborder@name}%
\fi

sichergestellt. (Das ist in meinem Beispiel im Prinzip auch der Fall, aber da es eh eine coordinate ist, ist das nicht von Relevanz.)

Timer

In allen Version bis auf der 2.10-cvs-Version wird als Ersatz der Timer der Linie -- verwendet. Bei der CVS-Version wird auf den Timer des arcs zurückgegriffen, wobei ich hier aber ordentlich geschummelt habe und die notwendigen Werte aus dem Scratch-Macro \pgf@marshal herausgeholt, die zu meinem Glück auch noch die richtigen sind. :D

Koordinaten-Systeme

Des Weiteren wird in PGF/TikZ zwischen Canvas-Koordinaten (mit Einheiten) und xy-Koordinaten (ohne Einheiten) unterschieden. Wenn ich das richtig sehe, versteht \pgfpatharcto nur Canvas-Koordinaten.

Ich habe mir erlaubt, einheitslose Radiusangaben ins xy-System zu schmeißen und die Längen der Basisvektoren als Radien für \pgfpatharcto zu verwenden. Das wird so oder so ähnlich auch an anderen Stellen verwendet, wobei dann aber direkt auf passendere PGF-Macros zurückgegriffen wird. Solange du allerdings das xy-System nicht in Relation zum Canvas-System drehst, sollten keine allzu überraschende Ergebnisse herauskommen. (Ich garantiere aber sicherheitshalber für nichts.)

Download

Der Code ist in die tikzlibrary.qrr.arc.code.tex-Library ausgelagert, die entsprechend mit

\usetikzlibrary{qrr.arc}

geladen werden muss.

Code

\documentclass[tikz,convert,png={size=600}]{standalone}
\usetikzlibrary{qrr.arc}
\begin{document}
\begin{tikzpicture}[ultra thick,dot/.style={label={#1}}]
\coordinate[dot=below left:$a$] (a) at (0,0);
\coordinate[dot=above right:$b$] (b) at (2,3);
\tikzset{nodes={circle,fill=white, fill opacity=.9, text opacity=1, inner sep=+0pt, sloped, allow upside down}}
\draw[blue]    (a) arc to[radius = 3cm]                    node[near start] {.25} node {.5} node[near end] {.75} (b);
\draw[red]     (a) arc to[radius = 3cm,            arc cw] node[near start] {.25} node {.5} node[near end] {.75} (b);
\draw[blue!50] (a) arc to[radius = 3cm, arc large]         node[near start] {.25} node {.5} node[near end] {.75} (b);
\draw[red!50]  (a) arc to[radius = 3cm, arc large, arc cw] node[near start] {.25} node {.5} node[near end] {.75} (b);

\fill[radius=2pt] (a) circle[] (b) circle[];
\end{tikzpicture}
\end{document}

Resultat