Export from RStudio

Simply plot(p) and select the Export button above the static plot. Choose a file name and location for your plot.

Because plot() actually turns the loon plot into a grid graphic, the picture saves will be close but not necessarily exactly as it appears on screen. Typical differences include font sizes and names.

Use l_export()

This is a loon function to export a loon plot to a file. On the plus side, what you see is what you get. The loon plot saved to the file will be the same as it appears on the display.

Trouble is, depending on your OS, you might not be able to save the picture as any type of image. For example, pdf images will be available to nearly all OSes, png will not. You do need to specify the file suffix:

l_export(p, filename = "myplot_via_l_export.pdf", height = 500, width = 600)

Use R’s png() device

In R, there are a variety of graphics “devices”. These identify where R will draw a static plot. The call dev.cur() will tell you what the current device is.

One such device is png() which allows R plots to be drawn as a png graphic. It would work like this

# turn the png graphics device on with name of the file
png(file = "myplot_via_R.png", width = 600, height = 500)
# Draw the static plot
plot(p)
# Turn the device off/close the file
dev.off()

Including saved graphics in your report

Having saved various snapshots to various files, you can now include them in your Rmarkdown file using the include_graphics() function from knitr.

Of course, this means that the various files mentioned above were previously saved (not created in the markdown file) and so can now be read into your RMarkdown report as follows:

# The one exported from RStudio
knitr::include_graphics("myplot_via_RStudio.png")
# Followed by the one saved using l_export 
# (note that background grid is missing)
knitr::include_graphics("myplot_via_l_export.pdf")
# And finally, the one saved using R's png device
knitr::include_graphics("myplot_via_R.png")

Alternatively, you could use LaTeX if you want more control. For example, the following LaTeX code would centre the three plots in each column of a tabular lay out:

\begin{center}
  \begin{tabular} {ccc}
    \includegraphics[height = 0.15\textheight]{myplot_via_RStudio.png} & 
    \includegraphics[height = 0.15\textheight]{myplot_via_l_export.pdf} &
    \includegraphics[height = 0.15\textheight]{myplot_via_R.png} 
    \\
    {\scriptsize The one exported from RStudio} & 
    {\scriptsize The one saved using \code{l\_export}} & 
    {\scriptsize The one saved using R's \code{png} device}
  \end{tabular}
\end{center}

A simple example

A typical use will be simply recording the plot after some interaction with the display, usually involving linking between two displays, say the scatterplot and histogram above.

We save the states of the plot p in a file as

l_saveStates(p, file = "p_savedStates")

Later, when we construct a new plot (perhaps for a report), the states are recovered from file

p_savedStates <- l_getSavedStates(file = "p_savedStates")

A new plot is constructed and the saved states transferred to it.

new_p <- l_plot(iris$Petal.Width, iris$Petal.Length)
l_copyStates(source = p_savedStates, target = new_p)

and can be programmatically incorporated into a report as

plot(new_p)

Again, alternatively new_p could simply be a reconstruction so as to continue an interactive analysis from that point.

A more complex example

Again, by default, only the following states related to linking are saved

names(p_savedStates)

## [1] "color"        "active"       "selected"     "linkingKey"   "linkingGroup"

[1] "color" "active" "selected" "linkingKey" "linkingGroup"

Sometimes, the interactive analysis will have been more involved. It could, for example, have involved panning and zooming, changing of glyphs, particular choices for labels and titles, and so on.

For example, through direct manipulation of the loon plot and inspector, the scatterplot p might at some point look something like this:

Here, the analyst zoomed in on the species “versicolor”, jittered the locations of the points, and changed some of the glyphs to be large closed triangles. This involves many more states, all of which must be saved to reproduce the plot.

The states to be saved can be named explicitly to be most efficient in storage, providing of course one knows which are the states that need to be saved.

All of the states of a loon plot p are given by names(p). At the risk of saving more information than necessary, we could choose to save all of the states of p, as in

l_saveStates(p, 
             states = names(p), 
             file = "p_focusOnVersicolor")

Now all of the states are available when this file is read back in.

p_focusOnVersicolor <- l_getSavedStates(file = "p_focusOnVersicolor")

When it comes to transferring the states to a new plot there are many choices. We could go with a large collection of display states (more than the default states but still excluding more “basic” states about panning and zooming for example). To see which states, we add the argument returnNames = TRUE:

l_copyStates(source = p_focusOnVersicolor, 
             target = new_p, 
             returnNames = TRUE)

This excluded “basic” states through the argument excludeBasicStates whose default value is TRUE.

More, or different, states could be excluded by using the argument exclude to list them in a vector. Alternatively, the only states to be transferred could be made explicit by naming them in the value of the argument states.

Because the “basic” states were excluded by default, the new plot now looks like

plot(new_p)

As can be seen, the glyph sizes and shapes were transferred but not the zooming or the jittering. To ensure we get an exact copy, we need to include all of the states, that is to exclude none of them.

l_copyStates(source = p_focusOnVersicolor, 
             target = new_p, 
             excludeBasicStates = FALSE)

Now the new_p should look much like the original interactive plot did when it was saved.

plot(new_p)

which it does.