8

While babysitting my kids yesterday I played little bit with one of my favorite LaTeX package PSTricks. Naturally I started toying with something more "advanced" so a toyed a bit with animations. On PSTricks website I learned about animate package. To expend further on the topic I also read a PracTEX Journal, 2010, No. 1. article, Tools for creating LATEX-integrated graphics and animations under GNU/Linux. Long story short 2 hours latter I came up with the following conclusions.

  1. Including animations into pdf files as oppose to using external files and external media players should be preferable approach in handling animations in presentations at least when it comes to portability.

  2. I like the idea of using external scripting language to do actual animations in pdf files instead of generating pdf files of enormous size.

  3. Animate takes the right approach but it fails short to deliver for two reasons. It requires Adobe Reader which is essentially Windows specific application. I am an OpenBSD user and the obsolete 7.0 version of Linux AcroRead which I can get to work via Linux emulation layer is compiled without required JavaScript. Why JavaScript? Since I do not actually use AcroRead my guess is that that is probably the only language it is supported.

Here is my question. Does anybody knows enough about internals of animate package to tell me how easily would be to replace JavaScript with Lua :) Second question for xpdf (or other pdf viewers based on different pdf rendering libraries like mupdf or epdfview) hackers is how easily would be to add Lua support in xpdf. Advantage of "my" approach should be obvious.

I would like to thank Dr. Herber Voss for doing a great job with PSTricks. The only really useful thing for humanity which came out of my goofing of with PSTricks yesterday and animate package is that I ordered his book PSTricks: Graphics and PostScript for TeX and LaTeX for our university library.

cmhughes
  • 100,947
Predrag Punosevac
  • 9,273
  • 1
    It's not that animate is lacking features but it's because only AcroRead has the abilities to pull of those tricks. And it's not Windows specific. as far as I know. – percusse Nov 04 '12 at 15:12
  • Well animate is guilty in taking opportunistic approach and using AcroRead instead of making truly portable solution in spirit of original TeX. Do not forget that TeX predates Windows by almost 20 years and even DOS for almost 10 years. – Predrag Punosevac Nov 04 '12 at 15:18
  • 3
    Animations are not TeX specific they use the PDF specifications and viewer resources. Also TeX has no idea of what animation is let alone creating them. So the question is addressing the wrong party in my humble opinion. In that sense Lua solutions are guilty in the same manner. – percusse Nov 04 '12 at 15:20

2 Answers2

7

animate uses JavaScript because if you want animations in PDF you need either an external program (i.e. you have to include movies) or scripting support in the viewer - and the only viewer with scripting support is Adobe Reader with JavaScript. So Lua won't help you there unless you also have a viewer with Lua support (which would make you PDFs incompatible to Adobe Reader), or include a Lua interpreter written in JavaScript.

Martin Schröder
  • 15,156
  • That was my guess (please see the question). So the follow up question was how difficult would be to add Lua support into PDF viewers xpdf, epdf, or mupdf (I am just listing one viewer for each of three open source pdf rendering libraries that I am aware of). You out of all people should prefer Lua over JavaScript for the same reason we do not have JavaScriptTeX but rather LuaTeX:) – Predrag Punosevac Nov 05 '12 at 17:00
4

Scalable Vector Graphics (SVG) can be used as an alternative output format.

Package animate is now able to produce animated SVG, thanks to M. Giesekings's dvisvgm backend/utility. This extends its usability to other platforms and viewers, namely Web browsers. See this topic: Using the animate package without Adobe.

AlexG
  • 54,894