# Rotation by a non-integer amount

I have to apply a very slightly rotation to an image, a rotation of less than 1º. But it looks like all the rotation commands I've found can handle only integer angles: all the non-integer measures are truncated to a whole number. Therefore, it is impossible to get a <1º rotation. I've tried to do the rotation with the \includegraphics, \rotatebox and the rotating package.

Of course, the problem is not to rotate one image but some hundreds of them. And 1º is quite relevant in a 20x20cm image inside a perfectly square frame.

-
Can you rotate the image in some other graphics package before you \include it? – Ethan Bolker Jan 31 '13 at 17:56
Welcome to TeX.SX. A tip: If you indent lines by 4 spaces, then they're marked as a code sample. You can also highlight the code and click the "code" button ({}). Usually, we don't put a greeting or a "thank you" in our posts. While this might seem strange at first, it is not a sign of lack of politeness, but rather part of our trying to keep everything very concise. Upvoting is the preferred way here to say "thank you" to users who helped you. – Claudio Fiandrino Jan 31 '13 at 18:03
Are you able to notice a difference of less than one degree? A quick test using box widths shows proper rotations for non-integer rotation angles. – Werner Jan 31 '13 at 18:05
Thank you for your answers. Looks like there are two possible solutions, one is using Tikz and the other using the rotation commands from graphicx. Regarding graphicx, the answers provided by David Carlisle do not work in my system (which happens to be XeTeX 3.1415926-2.3-0.9997.5). I don't get the same results and there is no difference between 1 and 1.5 degree rotations, neither have an explanation for this behavior. But using TikZ solves the problem, any arbitrary rotation can be performed with TikZ. – Tarasque Feb 1 '13 at 0:45
No they are not truncated by latex (I wrote that code so I have some vague recollection what it does) the actual rotation that happens (or not) depends of course on the back end, whether it is pdf or a dvi driver or whatever. – David Carlisle Feb 1 '13 at 1:08

\rotatebox should work with non integer values:

\documentclass{article}
\usepackage{graphicx}

\begin{document}

aaa{\count0=0
\loop
\rlap{\rotatebox{\the\count0}{hello world}}%
\ifnum\count0<90
\rlap{\rotatebox{\the\count0.5}{hello world}}%
\repeat
}

\end{document}


I was asked in chat for a different example

\documentclass{article}
\usepackage{graphicx,color}
\begin{document}
a%
\def\aaa{aaaaaaaaaaaaaaaaaaaaaaa}%
\rlap{\color{green}\rotatebox{1.5}{\aaa}}%
\rlap{\color{green}\rotatebox{-1.5}{\aaa}}%
\rlap{\rotatebox{1}{\aaa}}%%
\rlap{\rotatebox{-1}{\aaa}}%%
\end{document}

-
Good answer! I just checked your last example with the different TeX flavours: pdflatex, lualatex, xelatex and latex (both the PS and the converted PDF) and all show the same result, proving that graphicx can rotate with fractional angles. – Martin Scharrer Feb 1 '13 at 7:02
I repeated the tests with +/-1.1 and +/-1.01 angles which work fine as well. – Martin Scharrer Feb 1 '13 at 7:08

David Carlisle's answer is perfectly correct but its example is not demonstrative.

Here is an example via TikZ (a rotation of 0.25°):

\documentclass[tikz]{standalone}
\def\mytext{Very long text to show a small rotation.}
\begin{document}
\begin{tikzpicture}
\node[inner sep=0,anchor=west,text=red]{\mytext};
\node[inner sep=0,anchor=west,rotate=.25,text=blue]{\mytext};
\end{tikzpicture}
\end{document}


Here the same example via \rotatebox:

\documentclass{article}
\usepackage{graphicx}
\usepackage{xcolor}
\pagestyle{empty}
\def\mytext{Very long text to show a small rotation.}
\begin{document}
\textcolor{red}{\rlap{\rotatebox{0}{\mytext}}}%
\textcolor{blue}{\rlap{\rotatebox{0.25}{\mytext}}}%
\end{document}

-
If I'm not mistaken here they are using the same mechanism for rotation. – percusse Feb 1 '13 at 1:18
@percuße: They both use PDF or PS instructions to get the content rotated by the viewer, but both have different TeX drivers to produce these instructions, so there might be different limitations or influences like rounding errors etc. – Martin Scharrer Feb 1 '13 at 6:57
I'm curious as to whether the differences are due to rasterisation or are real differences. There appears to be a step discontinuity between the 'l's in "small" in the second version. – Loop Space Feb 1 '13 at 9:56
@MartinScharrer As far as I remember reading those, they use the same specials and both have independent (yet agreeing) instructions for each driver which is understandable since T. Tantau seems really studied hard the syntax of graphicx,pstricks etc. to a great extent. – percusse Feb 1 '13 at 11:15
@AndrewStacey The differences are due to rasterization. My picture are 250dpi. At 200dpi or 300dpi, there is no step discontinuity . – Paul Gaborit Feb 1 '13 at 12:32