# Tips and tricks to tightly couple LaTeX paper and Beamer presentation

My typical approach is to write the paper in LaTeX, then (in a new file) to write the presentation in Beamer.

I am now getting to the point in my education/career where the first version of a paper and presentation won't be the last. The two will evolve together over some (hopefully not too long) period of time.

Is there a better way to handle this combined evolution? I already write all graphs and tables to file, so these continuously update, but are there any other techniques that help?

• You're looking for things beyond just using beamerarticle, I assume? – Mike Renfro May 14 '12 at 14:30
• @MikeRenfro -- Yes (although I didn't know about beamerarticle, which will come in handy elsewhere, I'm sure). I am just looking for any tips/tricks/packages on making the presentation match the paper. There may not be any other than starting the beamer file from a relatively finished version of the paper then updating the presentation as the paper evolves. – Richard Herron May 14 '12 at 14:42
• Maybe the laziest/lamest example would be keeping the section titles and organization the same. Or keeping the same tables and graphs in both files. – Richard Herron May 14 '12 at 14:44
• Right, which is part of what beamerarticle does. If you've not looked yet, see section 21.2 of the beamer user guide, particularly section 21.2.2 (Workflow). – Mike Renfro May 14 '12 at 18:35
• I have to admit that my advice would be: don't do this. What you present on the screen and what you present on paper should be thought out carefully for each medium, and what works well for one will not necessarily work well for the other. Trying to use the same bits in each will make you more focussed on "saving" effort and less on making the best of each medium with the result that at least one will suffer. Most likely the presentation, and if that isn't good then it won't persuade anyone to read the article. – Loop Space May 14 '12 at 18:52

One good tip I think is to embed the code (e.g. R code) which generates your figures and tables in your document. This way generating a new version of the paper just requires you to recompile the entire document, including the scripts which generate the figures and tables. An example of such a system is the way R code and latex are merged using Sweave or knitr. You could put the code in a single repository, accesible by both the paper and tge presentation.

• +1 for Sweave (knitr is next on the list for me to learn)! – Richard Herron May 14 '12 at 19:21
• This may or may not be relevant, but there are languages beyond R that allow inline code, e.g. Sage (superset of Python). (Also, this is similar, although not identical, to literate programming) – huon May 15 '12 at 13:43

I agree with the comment saying that you should let the your article and your presentation be more or less independent in that the mediums are so different. What you can do to help with the issue of maintaining an article and a presentation of the same topic is to use some technology. Here are some things that might helpful:

• Version control. With this you do not have to be afraid of making radical changes to your work because you can go back to earlier versions. Track you article with git and then branch when you want to convert it to a beamer presentation.
• Templates. Make a beamer template so that you can easily get started on beamer presentations.
• Org-mode. You can export both to LaTeX article and beamer presentation from Org-mode and it is all possible to track with version control.

None of these answers are wrong, but I have a number of things that work well for me.

Figures, Tables, Theorems and other floats - Rather than include the code for the floats in the paper itself, I write them in separate files, that I save in relevant folders. When I put them in the paper I simple \include{file}. When I build my presentation, it is just a matter of doing the same in a frame. When doing this, however, it is important to use relative sizes rather than absolutes (i.e. .8\linewidth and not 10cm) so that things fit the page they are on.

Graphs - I work in R, so I export to LaTeX by way of Tikz. There is a Tikz module in R, and this makes it so that every graph is native to whatever medium you are using as a Tikz graphic. This also means that universal changes, such as font, will affect the graph, which is very helpful in most cases, but must be watched.

Overall Format - Papers do not generally translate well to presentations in the order that things are presented. For example, the conclusion should be up front in presentations, but some papers save the conclusion for the end. This isn't a magic show. That said, it is sometimes very helpful to write or give presentations to help build the paper, because you discover how people understand, or don't, the logic of your paper. That said, putting aside differences in styles of writing, keeping the paper and the presentation closely tied works well for me.