[Tex/LaTex] Changing arrow colour in smartdiagram

colorsmartdiagramtikz-arrowstikz-pgf

The smartdiagram package appears to have a default convention that an arrow in a circular diagram takes the colour of the destination block. Is there a way to choose instead the colour of the source block as the colour of the arrow.
For instance, in this example

\documentclass{article}
\usepackage{tikz}
\usepackage{smartdiagram}
\begin{document}
\smartdiagramset{set color list={red!50,orange!50,green!50}}
\smartdiagram[circular diagram:clockwise]{Red,Orange,Green}
\end{document}

I want the arrow from "Red" to "Orange" to be red instead of orange. In other words, I want to advance all arrow colours one step clockwise.

Is there a single key or other simple option to do this? If there isn't might I suggest it through this forum please?

Best Answer

Code

\documentclass[tikz,convert=false]{standalone}
\usepackage{smartdiagram}
\makeatletter
\smartdiagramset{
  flip arrow colors/.style={
    /tikz/diagram arrow type/.prefix code={%
      \edef\col{\@nameuse{color@\xi}}%
    }
  }
}
\makeatother
\begin{document}
\smartdiagramset{set color list={red!50,orange!50,green!50}}
\smartdiagram[circular diagram:clockwise]{Red,Orange,Green}

\smartdiagramset{flip arrow colors}
\smartdiagram[circular diagram:clockwise]{Red,Orange,Green}
\end{document}

Output

enter image description here

Related Solutions

[Tex/LaTex] How to put a coloured outline around fraction lines

Knuth in the TeXBook gave an example of "poor man's bold," (The TeXbook, p. 386) which can be typeset obtained by overprinting the normal weight symbol with slight offsets.

As he says:

The results are somewhat fuzzy, and they certainly are no match for the real thing if it's available; but poor man's bold is better than nothing, and once in a while you can get away with it.

Here, one can use a similar technique and the code is shown below:

\documentclass{article}
\usepackage{graphicx,xcolor} 
\usepackage{amsmath}
\def\PoorManContour#1#2#3{\leavevmode
    \setbox0=\hbox{{#1}}%
    \color{#3}\kern-.002em\copy0\kern-\wd0
    \color{#3}\raise-.04em\copy0\kern-\wd0
    \color{#3}\lower.04em\copy0\kern-\wd0
    \color{#3}\raise0.04em\copy0\kern-\wd0
    \color{#2}\raise-.012em\copy0\kern-\wd0
    \color{#2}\kern.06em\copy0\kern-\wd0
    \color{blue}\kern-.020em\lower.003em\box0
}
\begin{document}
\colorbox{gray!5}{\scalebox{5}{\PoorManContour{$\sqrt{\dfrac{A^3_i}{B^2}}$}{gray!60}{gray!60}}}
\end{document}

To achieve the best results possible one has to kern in small steps for possibly twenty steps or so. For simplicity, I have not done that. In the final version, you need to adjust the colors to suit, possibly changing the shading to white.

alt text

Edit

After reading Jan's comment below I read the manual and true, as the commenter said the easiest way to achieve what the OP wanted is to include the package without an option i.e., \usepackage{contour}. Helps to RFM!

[Tex/LaTex] Controlling arrow distance from the destination node in TikZ

Well, I don't know why it is happening but I know where it is happening. The arrowhead stealth' is the culprit and amazingly it gets affected by the line

\renewcommand{\baselinestretch}{2}

regardless of the amount put inside the definition. ~~You don't see that with other arrow heads.~~ It happens with arrows library specific arrows. Here is a much simpler MWE (I wish you did this for us but anyway)

\documentclass{article}
\usepackage{tikz}
\usetikzlibrary{arrows}
\begin{document}

\begin{tikzpicture}
\node[draw] (A) {$q_a$};
\node[draw] (B) at (1,0) {a};
\draw[-stealth'](A) -- (B);
\end{tikzpicture}

\renewcommand{\baselinestretch}{2}

\begin{tikzpicture}
\node[draw] (A) {$q_a$};
\node[draw] (B) at (1,0) {a};
\draw[-stealth'](A) -- (B);
\end{tikzpicture}
\end{document}

enter image description here

David Carlisle also indicated that there is a font selection issue or absence of it for reasons beyond me. Hence,

\renewcommand{\baselinestretch}{2}\selectfont

brings the arrow back to the node border. But I don't know what it breaks....

Long story short this is very likely to be related to the way how \nullfont declaration is invoked. For example, putting \selectfont\nullfont as the first code inside the TikZ picture also removes the artifact. So at some point before TikZ starts to do its job font selection should be finished so that one can switch to the \nullfont properly.

Thus, David's comment below is very important.