make pdfs pngs

plain-person-text.md

@@ -74,7 +74,7 @@ In the social sciences and humanities, you are most likely to have come across t
 
 Modern version control requires getting used to some new concepts related to tracking your files, and learning how your version control system implements these concepts. There are some [good resources](https://git-scm.com/book/en/v2) for learning them. Because of their power, these tools might seem like overkill for individual users. (Again, though, many people find Word's "Track Changes" feature indispensable once they begin using it.) But version control systems can be used quite straightforwardly in a basic fashion, and they  can often be easily integrated with your text editor, or used via a friendlier application interface that keeps you away from the command line. The core idea is shown in @fig:git. You keep your work in a *repository* containing both the files you've written and a complete record of changes to those files. This can be kept locally, or on a site like GitHub. As you work, you periodically *stage* your changes and then *commit* them to the repository, along with a little note about what you did. Repositories can be copied, cloned, merged, and contributed to by you or other people.
 
-![A schematic `git` workflow. (1) You get the most recent version of your project from a remote repository (such as GitHub), and then (2) You "check-out" the project to work on, writing text or code, etc. You work on files as usual in a folder on your computer. But it is the repository that is "real" as far as the project is concerned. (3) You edit your documents, and once you are happy with the changes you *stage* them. Behind the scenes means the changes are added to an index that Git uses to keep track of things. But these changes are not yet permanently recorded. (4) You then *commit* the changes to the repository, along with a note about what you did. This is now a firm record of the changes. (5) You "push" the changes up to the remote repository, which in effect also functions as a backup of your work. Over time, the repository comes to contain a complete record of the project, any step of which can be revisited as needed. In the simplest case there is no remote repository, only a local one you check out and commit changes to. You can do all this from the command line, or use one of several front-end applications designed to help you manage things.](figures/git-basic.pdf){#fig:git}
+![A schematic `git` workflow. (1) You get the most recent version of your project from a remote repository (such as GitHub), and then (2) You "check-out" the project to work on, writing text or code, etc. You work on files as usual in a folder on your computer. But it is the repository that is "real" as far as the project is concerned. (3) You edit your documents, and once you are happy with the changes you *stage* them. Behind the scenes means the changes are added to an index that Git uses to keep track of things. But these changes are not yet permanently recorded. (4) You then *commit* the changes to the repository, along with a note about what you did. This is now a firm record of the changes. (5) You "push" the changes up to the remote repository, which in effect also functions as a backup of your work. Over time, the repository comes to contain a complete record of the project, any step of which can be revisited as needed. In the simplest case there is no remote repository, only a local one you check out and commit changes to. You can do all this from the command line, or use one of several front-end applications designed to help you manage things.](figures/git-basic.png){#fig:git}
 
 Revision control has significant benefits. A tool like Git combines the virtues of "track changes" with those of backups. Every repository is a complete, self-contained, cryptographically signed copy of the project with a full record of every recorded step in its development by all of its participants. This puts you in the habit of recording (or \`\`committing'') changes to a file or project as you work on it, and (briefly) documenting those changes as you go. It allows you to easily test out alternative lines of development by branching a project. It allows collaborators to work on a project at the same time without sending endless versions of the "master" copy back and forth via email, and it provides powerful tools that allow you to automatically merge or (when necessary) manually compare changes that you or others have made. Perhaps most importantly, it lets you revisit any stage of a project's development at will and reconstruct what it was you were doing. This can be tremendously useful whether you are writing code for a quantitative analysis, managing field notes, or writing a paper. While you will probably not need to control everything in this way (though some people do), I *strongly* suggest you consider managing at least the core set of text files that make up your project (e.g., the code that does the analysis and generates your tables and figures; the dataset itself; your notes and working papers, the chapters of your dissertation, etc). As time goes by you will generate a complete, annotated record of your actions that is also a backup of your project at every stage of its development. Services such as [GitHub](http://www.github.com) allow you to store public or (for a fee) private project repositories and so can be a way to back up work offsite as well as a platform for collaboration and documentation of your work.
 
@@ -151,7 +151,7 @@ RMarkdown is one of several "literate programming" formats. The idea goes back t
 @fig:example-figure-r, for instance, could be generated on the fly from source-code blocks included in the `.Rmd` source for this article. Sometimes we will want to only show the results produced by the code---in this case, @fig:example-figure-r. But at other times we will want to display the code as well, as in @lst:r-example. 
 
 
-![Tea and Biscuits](figures/example-figure-1.pdf){#fig:example-figure-r}
+![Tea and Biscuits](figures/example-figure-1.png){#fig:example-figure-r}
 
 ```{#lst:r-example .r caption="R code snippet."}
 
@@ -178,7 +178,7 @@ The literate programming approach has its limits. For large or complex analyses
 
 We write papers. Those papers cite books and articles. They often incorporate tables and figures created in [R](http://www.r-project.org). What we want to do is quickly turn a Markdown file containing things like that into a properly formatted scholarly paper, without giving up any of the necessary scholarly apparatus (on the output side) or the convenience and convertibilty of Markdown (on the input side). We want to easily get good-looking output from the same source in HTML, PDF, and DOCX formats. And we want to do that with an absolute minimum of---ideally, *no*---post-processing of the output beyond the basic conversion step. This is within our reach.
 
-![A plain-text document toolchain.](figures/workflow-wide.pdf){#fig:workflow-diagram}
+![A plain-text document toolchain.](figures/workflow-wide.png){#fig:workflow-diagram}
 
 A sample document flow is shown in @fig:workflow-diagram. I promise it is less insane than it appears. Describing it all at once might make it sound a little crazy. But, at bottom, there are just two separable pieces. First, `knitr` converts `.Rmd` files to `.md` files. Second, John MacFarlane's superb [Pandoc](http://johnmacfarlane.net/pandoc/) converts `.md` files to HTML, `.tex`, PDF, or Word formats. In both cases we use a few switches, templates and configuration files to do that nicely and with a minimum of fuss. You should install a standard set of Unix developer tools, which on OS X can  conveniently be installed [directly from the command line](https://developer.apple.com/library/ios/technotes/tn2339/_index.html).[^commandline] along with R, knitr, pandoc, and a [TeX distribution](https://tug.org/mactex/). Note that the default set-ups for `knitr` and `pandoc`---the two key pieces of the process---will do most of what we want with no further tweaking. What I will you here are just the relevant options to use and switches to set for these tools, together with some templates and document samples showing how nice-looking output can be produced in practice.