A scaling problem in animate- package

Question

System: Windows 7, WinEdt 7, MikTeX 2.9.

I am trying to include animations of a rotating cube into my powerdot slide sets. A problem I ran into this time is that the images are cropped out for some reason. The previous time I had no problems using the parameters height, width, keepaspectratio et cetera. This time something went wrong. Below there are two screen shots of the relevant slide together with the TeX-source.

\begin{slide}{Esimerkki 4.A3}
$\sigma_1=$ rotaatio 90 astetta $z$-akselin ympäri.

\animategraphics[keepaspectratio,height=400pt,autoplay,loop,scale=0.6]{12}{RotZ}{0}{64}
\end{slide}

Gives rise to

If I try it with different value for scale

\begin{slide}{Esimerkki 4.A3}
$\sigma_1=$ rotaatio 90 astetta $z$-akselin ympäri.

\animategraphics[keepaspectratio,height=400pt,autoplay,loop,scale=0.7]{12}{RotZ}{0}{64}
\end{slide}

I get the following

Without scaling I get an overfull box error message as I should, because height 240 pt is about what you can comfortably fit into a single powerdot-slide without disturbing the borders. If I leave out the paramater scale, and assign height=160pt or something reasonable (which is what I did in the past when including the animation worked), the cropping becomes worse. Only a small fraction of the rotating cube remains visible then.

It is as if there is a white box overwriting the animation at the top of the slide?

That 400 points should really be postscript points. If I view an individual frame (they are all .eps-files) with GSView, the interesting area has LL at (20,20) and UR at (350,380) or thereabouts.

Answer 1

Not sure whether it is related, but the following bug from section 9 of the manual to animate package somehow fits the symptoms. Locating + downloading epsffit, and running it on all the 64 files is not my idea of fun :-(

If the LATEX -> dvips -> ps2pdf/Distiller route is being taken, make sure that the original graphics size (i. e. not scaled by any of the ‘scale’, ‘width’, ‘height’ or ‘totalheight’ options) does not exceed the page size of the final document. During PS to PDF conversion every graphic of the animation is temporarily moved to the upper left page corner. Those parts of the graphics that do not fit onto the document page will be clipped in the resulting PDF. Fortunately, graphics files for building animations may be resized easily to fit into a given bounding box by means of the ‘epsffit’ command line tool: epsffit -c infile.eps outfile.eps are the bounding box coordinates of the target document. They can be determined using Ghostscript. For a document named ‘document. ps’ the command line is gs -dNOPAUSE -q -dBATCH -sDEVICE=bbox document.ps Note that the name of the Ghostscript executable may vary between operating systems (e. g. ‘gswin32c.exe’ on Win/DOS).

Problem is now solved!

My misunderstanding was that the animate package would always scale the eps images from whatever size they happen to be to fit into the box assigned to the animation. Just like includegraphics does. This is not the case (I don't know why this is technically not possible, so I'm leaving that for somebody else to explain), so to solve my problem I had to recreate versions of the images that fit into the page.

In my case that amounted to studying Mathematica manual, and locating the option ImageSize when exporting images in eps-format. Giving that parameter a value like 150 (most likely PostScript point) fixed the problem. Now I'm happy to say that the LaTeX snippet

\begin{slide}{Esimerkki 4.A3}
$\sigma_1=$ rotaatio 90 astetta $z$-akselin ympäri on kertalukua neljä oleva symmetria.

\animategraphics[height=160pt,keepaspectratio,autoplay,loop]{12}{RotZ}{0}{64}
\end{slide}

produces a slide like

I will edit this answer to add this (IMO) necessary piece of information to the instructions given there.

It is not clear to what extent this question really was about LaTeX. I hope this was not off-topic.