# Combining vectors, accents and subscripts produces bad result

Combining vectors, accents and subscripts produces really bad results.

First row below shows combining vector and accent. In second example accent and vector symbol clash. In third example vector symbol is too far from 'r'. Fourth example is patch by adding some space to the second example and this is what I usually use.

Second row shows combining vector and subscript by including subscript under \vect command. I don't like result because vector symbol is moved to the right and no longer above 'r'.

Third row combining vector and subscript by putting subscript outside \vect command. None of the results are acceptable.

So how would you typeset those combinations? Is it possible to do that centrally, not by patching every single instance of the combination?

MWE:

\documentclass[12pt]{scrbook}
\usepackage{amsmath}

\begin{document}

\thispagestyle{empty}
\begin{align*}
\vec{r} \; \vec{r}' \; \vec{r'} \; \vec{r}\,'\\
\vec{r_\text{g}} \; \vec{r_\text{g}}' \; \vec{r_\text{g}'} \; \vec{r_\text{g}}\,'\\
\vec{r}_\text{g} \; \vec{r}_\text{g}' \; \vec{r'}_\text{g} \; \vec{r}_\text{g}\,'
\end{align*}

\end{document}


• – egreg Oct 2 '13 at 16:09

I'd simply back up a little the arrow:

\documentclass{article}
\usepackage{mathtools}
\DeclareRobustCommand{\zvec}[1]{%
\mathrlap{\vec{\mkern-2mu\phantom{#1}}}#1%
}
\begin{document}
\begin{gather*}
\zvec{r} + \zvec{r}' \\
\zvec{r}_\textnormal{g} + \zvec{r}_\textnormal{g}' + \zvec{r}_\textnormal{g}''
\end{gather*}
\end{document}


• I realised that my question is related to one you've already answered before tex.stackexchange.com/questions/120029/…. I find the previous solution more elegant, as it does not require additional package. What is advantage of this new solution? – Pygmalion Oct 2 '13 at 18:03
• @Pygmalion One can choose between the two; actually perhaps now I'd prefer this one, assuming I'd use the arrow for vectors, which I wouldn't. – egreg Oct 2 '13 at 20:55

I'm not capable of a fully-automated solution, but what I provide here is \shvec which gives you a \vec with the arrow shifted to the right by the number of pt's specified by the number given in the optional argument (default 0). As you might expect (and unfortunately), different letters require different shifts, in my opinion.

EDIT: In response to a follow-up from the OP, I revised the solution to provide not only the left-right shifting capability on the the original \vec, here given as \shvec BUT ALSO the same capability on a longer version of the \vec, here given as \shlongvec 8^0 .

I also streamlined the coding from before. I should point out that while stackengine package has a lot of shortcut macros like \stackon, \stackunder, etc., it is best if you are placing the stack into an oft used macro to just use the underlying \stackengine macro. By doing so, you avoid any need to redefine the default configurations of the package (meaning it won't adversely affect other stacking code in your document).

\documentclass[12pt]{scrbook}
\usepackage{stackengine}
\usepackage{xcolor}
\newlength\shlength
\newcommand\shvec[2][0]{\setlength\shlength{#1pt}%
\stackengine{-5.2pt}{$#2$}
{\smash{$\kern\shlength\mathchar"017E\kern-\shlength$}}{O}{c}{F}{T}{S}
}
\newcommand\shlongvec[2][0]{\setlength\shlength{#1pt}%
\stackengine{-5.2pt}{$#2$}{\smash{$\kern\shlength% \stackengine{4.42pt}{$\mathchar"017E$}{$-$}{O}{r}{F}{F}{L}\kern-\shlength$}}%
{O}{c}{F}{T}{S}}
\begin{document}
\centering
$\vec{A} \shvec[-.5]{r}'\shlongvec[.5]{A} \shlongvec[0]{w}$
\end{document}


From earlier edit:

One weird thing about the behavior of \shvec (that will take someone like egreg or Werner to explain) is why in some cases, for example \shvec[0]{R} does not give the same result as \vec{R}. To study this further, I created a debug mode where I used a red letter instead of a \phantom to show upon what the vector arrow was being placed. In \shvec[0]{R}, the red R overlays the black one, and yet clearly the vector arrow is not in the same place. Perhaps the \vec routine has customized letter-dependent kerning that is not employed when enclosing the letter in a \phantom or \textcolor. This doesn't mean that \shvec can't work with such letters, it just means that you need a non-zero value to recreate what \vec already does.

• I like this solution because it does not require loading any new packages. Still, I would have an additional question. IMHO, arrows above upright letters should be longer. Is it possible to fix the length too? So far I've used \usepackage[e]{esvect} and it's just not looking the same as plain \vec – Pygmalion Oct 2 '13 at 14:28
• @Pygmalion Well, when not debugging, one can dispense with xcolor. However, \shvec does use stackengine package. As the author, I can attest that it is a small package that doesn't carry a lot of overhead to load, and doesn't itself load any other packages (as of a recent revision). – Steven B. Segletes Oct 2 '13 at 14:33
• Oh, yes, I overlooked using stackengine. :) What about extending arrows? Is that possible too? – Pygmalion Oct 2 '13 at 14:38
• I am sorry, I have studied your solution and only now I realised you actually use the generic \vec command, just moving arrow around. I guess long arrows would require a completely different approach. I'll wait just for a while and if nothing interesting appears, I shall use your solution. – Pygmalion Oct 2 '13 at 14:49

I should use the esvect package.

• in Its current form your answer is very short but seems to point into the right direction. Maybe you want to elaborate a bit more and also add some code example? – Benedikt Bauer Oct 2 '13 at 12:24
• I actually know about esvect package and I don't like the result it produces. – Pygmalion Oct 2 '13 at 14:31