Fetching contributors…
Cannot retrieve contributors at this time
878 lines (653 sloc) 56 KB
# [pander: An R Pandoc Writer](
The main aim of the *pander* [R]( package is to provide a minimal and easy tool for rendering **R objects** into [Pandoc]('s **markdown**. The package is also capable of exporting/converting complex Pandoc documents (reports) in [various ways](#creating-pandoc-documents). Regarding the difference between `pander` and other packages for exporting R objects to different file formats, please refer to this [section](#difference-from-other-rendering-packages).
Current build and test coverage status: [![](]( [![](](
Some CRAN statistics: [![](]( [![](](
# Installation
The stable version [![](]( can be installed easily in the `R` console like any other package:
On the other hand, I welcome everyone to use the most recent version of the package with quick-fixes, new features and probably new bugs. It's currently hosted on [GitHub]( To get the latest development version from [GitHub]( of the `devtools` package from [CRAN](
Or download the [sources]( and build manually. If you're running R on Windows, you will need to install [Rtools](
## Dependencies
Few cool packages from CRAN are needed for installing and/or using `pander`:
* [digest]( to compute hashes while caching,
* [Rcpp]( to compile certain functions used by the package.
And there are also a few optional suggested or supported R packages, such as:
* [koRpus]( to use hyphenation when splitting large table cells,
* [lattice]( and [ggplot2]( for unified plot theme,
* [futile.logger]( for logging capabilities inside `evals`,
* [survival](, [microbenchmark](, [zoo](, [nlme](, [descr](, [MASS](, [tables](, [reshape](, [memisc](, [Epi](, [randomForest](, [tseries](, [rms]( packages include some supported R classes,
* and *pander* can be also very useful inside of [knitr]( More information about how to use *pander* and *knitr* can be found specialized vignette, which can be accessed by `vignette('knitr', package = 'pander')` or available online [here](
### Pandoc
*pander* heavily builds on [Pandoc](, which should be **pre-installed** before trying to convert your reports to [different formats]( Although **main functions work without Pandoc**, e.g. you can transform R objects into markdown or generate a markdown formatted report via [Pandoc.brew](#brew-to-pandoc) or the custom [reference class](#live-report-generation), but installing that great piece of software is suggested if you want to convert markdown to PDF/docx/HTML or other formats.
Starting v0.98.932 [RStudio]( comes with a bundled `Pandoc` binary, so one can save the tedious steps of installing Pandoc.
If you do not have RStudio installed, please refer to the [installation process of Pandoc](, which is quite straightforward on most-popular operating systems: download and run the binary (a few megabytes), and get a full-blown document converter in a few seconds/minutes. On some Linux distributions, it might be a bit more complicated (as repositories tend to provide out-dated versions of Pandoc, so you would need `cabal-install` to [install from sources]( Please do not forget to restart your R session to update your `PATH` after installation!
# Helper functions
The package contains numerous helper functions, which render user specified inputs in Pandoc's markdown format or apply some extra formatting on it. All Pandoc-related functions' names are starting with `pandoc`. For example `pandoc.table` is used for rendering tables in markdown. For a technical documentation, see the HTML help files of the package at [Rdocumentation](
<a id="primitive-functions"></a>
All `pandoc` functions generally prints to console and do not return anything by default. If you want the opposite, to get markdown in a string, call each function ending in `.return`, for example `pandoc.table.return`. For more details, please see the official documentation in e.g. `?pandoc.strong`.
The full list of currently available primitive Pandoc-related functions are:
* pandoc.indent
* pandoc.p
* pandoc.strong
* pandoc.emphasis
* pandoc.strikeout
* pandoc.verbatim
* pandoc.image
* pandoc.formula
* pandoc.footnote
* pandoc.horizontal.rule
* pandoc.header
* pandoc.title
<a id="lists"></a>
For example there is a helper function rendering R **lists** into markdown:
> l <- list(
+ "First list element",
+ paste0(1:5, '. subelement'),
+ "Second element",
+ list('F', 'B', 'I', c('phone', 'pad', 'talics')))
> pandoc.list(l, 'roman')
Which command produces the following output:
l <- list("First list element", paste0(1:5, '. subelement'), "Second element", list('F', 'B', 'I', c('phone', 'pad', 'talics')))
pandoc.list.return(l, 'roman')
<a id="tables"></a>
# Markdown tables
One of the most popular feature in *pander* is `pandoc.table`, rendering most tabular R objects into markdown tables with various options and settings (e.g. [style](#style), [caption](#caption), [cell highlighting](#highlight-cells), [cell alignment](#cell-alignment), [width](#table-and-cell-width)). This section aims to provide quick introduction to most common options, but for more usage/implementation details and examples, please refer to specialized vignette, which can be accessed by `vignette('pandoc_table')` or available online [here](
Let's start with a small example:
> pandoc.table(mtcars[1:3, 1:4])
Which command produces the following output by default:
```<%=mtcars[1:3, 1:4]%>
<a id="style"></a><a id="styles"></a>
Please note that all below features are also supported by the more concise `pander` [generic S3 method](#generic-pander-method)!
## Formats
All [four Pandoc formats]( are supported by *pander*. From those (*multiline*, *simple*, *grid*, *pipe/rmarkdown*), I'd suggest sticking to the default `multiline` format with the most features, except when using `rmarkdown` v1.0 or jupyter notebook, where `multiline` is not supported (for this end the default table format is `rmarkdown` when `pander` is called inside of a jupyter notebook). Please see a few examples below:
<a id="multiline-table"></a>
The default style is the [`multiline` format]( (except for calling `pander` inside of a of a jupyter notebook) as most features (e.g. multi-line cells and alignment) are supported:
> m <- mtcars[1:2, 1:3]
> pandoc.table(m)
pandoc.table.return(mtcars[1:2, 1:3])
While [`simple` tables]( are much more compact, but do not support line breaks in cells:
> pandoc.table(m, style = "simple")
pandoc.table.return(mtcars[1:2, 1:3], style = "simple")
My personal favorite, the [`grid` format]( is really handy for [emacs]( users and it does support line breaks inside of cells, but cell alignment is not possible in most parsers:
> pandoc.table(m, style = "grid")
pandoc.table.return(mtcars[1:2, 1:3], style = "grid")
And the so called `rmarkdown` or [pipe table format]( is often used directly with `knitr`, since it was supporters by the first versions of the `markdown` package:
> pandoc.table(m, style = "rmarkdown")
pandoc.table.return(mtcars[1:2, 1:3], style = "rmarkdown")
But once again, you should simply stick to the default [multiline table format](#multiline-table) in most cases. Otherwise, it's wise to update the default table format via [`panderOptions`](#pander-options).
## Caption
It's really easy to add a **caption** to a table:
> pandoc.table(m, style = "grid", caption = "Hello caption!")
pandoc.table.return(mtcars[1:2, 1:3], style = "grid", caption = 'Hello caption!')
For more convenient and flexible usage, you might be interested in the special `set.caption` helper function. Call the function at any time, and the next table or plot will catch up the provided caption:
> set.caption("Hello caption!")
> pandoc.table(m)
set.caption("Hello caption!")
pandoc.table.return(mtcars[1:2, 1:3])
Unless `permanent` option is set for `TRUE` (by default), caption will be set only for next table. To disable permanently set caption, just call `set.caption(NULL)` or call `set.caption` with `permanent` parameter being set to `FALSE`.
<a id="highlight-cells"></a>
## Highlighting cells
One of the fanciest features in *pander* is the ease of highlighting rows, columns or any cells in a table. This is a real markdown feature without custom HTML or LaTeX-only tweaks, so all HTML/PDF/MS Word/OpenOffice etc. formats are supported.
This can be achieved by calling `pandoc.table` directly and passing any (or more) of the following arguments **or** calling the R function with the same names before rendering a table with either the `pander` [generic S3 method](#generic-pander-method) or via `pandoc.table`:
* emphasize.italics.rows
* emphasize.italics.cols
* emphasize.italics.cells
* emphasize.strong.rows
* emphasize.strong.cols
* emphasize.strong.cells
* emphasize.verbatim.rows
* emphasize.verbatim.cols
* emphasize.verbatim.cells
The `emphasize.italics` helpers would turn the affected cells to *italic*, `emphasize.strong` would apply a **bold** style to the cell and `emphasize.verbatim` would apply a `verbatim` style to the cell. A cell can be also *italic*, **bold** and `verbatim` at the same time.
Those functions and arguments ending in `rows` or `cols` take a vector (like which columns or rows to emphasize in a table), while the `cells` argument take either a vector (for one dimensional "tables") or an array-like data structure with two columns holding row and column indexes of cells to be emphasized -- just like what `which(..., arr.ind = TRUE)` returns. A quick-example:
> t <- mtcars[1:3, 1:5]
> emphasize.italics.cols(1)
> emphasize.italics.rows(1)
> emphasize.strong.cells(which(t > 20, arr.ind = TRUE))
> pandoc.table(t)
t <- mtcars[1:3, 1:5]
emphasize.strong.cells(which(t > 20, arr.ind = TRUE))
pandoc.table(t, emphasize.verbatim.rows = 1, emphasize.strong.cells = which(t > 20, arr.ind = TRUE))
For more examples, please see our "[Highlight cells in markdown tables](" blog post.
## Cell alignment
You can specify the alignment of the cells (left, right or center/centre) in a table directly by setting the `justify` parameter:
> pandoc.table(head(iris[,1:3], 2), justify = c('right', 'center', 'left'))
pandoc.table.return(head(iris[,1:3], 2), justify = c('right', 'center', 'left'))
Or pre-define the alignment for (all future) `pandoc.table` or the `pander` [S3 generic method](#generic-pander-method) by a helper function:
> set.alignment('left', row.names = 'right')
> pandoc.table(mtcars[1:2, 1:5])
set.alignment('left', row.names = 'right')
pandoc.table.return(mtcars[1:2, 1:5])
Just like with [captions](#caption), you can also specify the `permanent` option to be `TRUE` to update the default cell alignment for all future tables. And beside using `set.alignment` helper function or passing parameters directly to `pandoc.table`, you may also set the default alignment styles with [`panderOptions`](#pander-options).
What's even more fun, you can specify a function that takes the R object as its argument to compute some unique alignment for your table based on e.g. column values or variable types:
> panderOptions('table.alignment.default',
+ function(df)
+ ifelse(sapply(df, mean) > 2, 'left', 'right'))
> pandoc.table(head(iris[,1:3], 2))
potad <- panderOptions('table.alignment.default')
panderOptions('table.alignment.default', function(df) ifelse(sapply(df, mean) > 2, 'left', 'right'))
pandoc.table.return(head(iris[,1:3], 2))
panderOptions('table.alignment.default', potad)
## Table and cell width
`pandoc.table` can also deal with the problem of really **wide tables**. Ever had an issue in LaTeX or MS Word when tried to print a correlation matrix of 40 variables? Not a problem any more as you can split up the table with auto-added captions. The `split.table` option defaults to 80 characters:
> pandoc.table(mtcars[1:2, ], style = "grid", caption = "Hello caption!")
gsub('\n\n \n\n', '\n\n', pandoc.table.return(mtcars[1:2, ], style = "grid", caption = 'Hello caption!'))
And too wide cells can also be split by line breaks. The maximum number of characters in a cell is specified by `split.cells` parameter (default to 30), can be a single value, vector (values for each column separately) and relative vector (percentages of `split.tables` parameter):
> df <- data.frame(a = 'Lorem ipsum', b = 'dolor sit', c = 'amet')
> pandoc.table(df, split.cells = 5)
df <- data.frame(a = 'Lorem ipsum', b = 'dolor sit', c = 'amet')
pandoc.table.return(df, split.cells = 5)
> pandoc.table(df, split.cells = c(5, 20, 5))
pandoc.table.return(df, split.cells = c(5, 20, 5))
> pandoc.table(df, split.cells = c("80%", "10%", "10%"))
pandoc.table.return(df, split.cells = c("80%", "10%", "10%"))
If the `koRpus` package is installed, `pandoc.table` can even split the cells with hyphening support:
> pandoc.table(data.frame(baz = 'foobar'), use.hyphening = TRUE, split.cells = 3)
pandoc.table.return(data.frame(baz = 'foobar'), use.hyphening = TRUE, split.cells = 3)
## Minor features
Funtionality described in other sections is most notable, but `pander/pandoc.table` also has smaller nifty features that are worth mentioning:
* `plain.ascii` - allows to have the output without `markdown` markup:
> pandoc.table(mtcars[1:3, 1:4])
pandoc.table.return(mtcars[1:3, 1:4])
> pandoc.table(mtcars[1:3, 1:4], plain.ascii = TRUE)
pandoc.table.return(mtcars[1:3, 1:4], plain.ascii = TRUE)
* `missing` - set a string to replace missing values:
> m <- mtcars[1:3, 1:5]
> m$mpg <- NA
> pandoc.table(m, missing = '?')
m <- mtcars[1:3, 1:5]
m$mpg <- NA
pandoc.table.return(m, missing = '?')
* `keep.line.breaks` - allows to preserve line breaks inside cells. Not that by default `pandoc.table` automatically omits all line breaks found in each table cell to be able to apply the `table.split` functionality.
> m <- data.frame(a="foo\nbar", b="pander")
> pandoc.table(m)
m <- data.frame(a="foo\nbar", b="pander")
> pandoc.table(m, keep.line.breaks = TRUE)
pandoc.table.return(m, keep.line.breaks = TRUE)
To see all possible options, please check [`?pandoc.table`](
And please note, that all above mentioned features are also supported by the `pander` [generic S3 method](#generic-pander-method) and defaults can be updated via [`panderOptions`](#pander-options) for permanent settings.
# Generic pander method
`pander` or `pandoc` (call as you wish) can deal with a bunch of R object types as being a pandocized `S3` generic method with a variety of already supported classes:
<a id="supported-r-classes"></a>
> methods(pander)
[1] pander.anova* pander.aov* pander.aovlist* pander.Arima**
[6] pander.cast_df* pander.character* pander.clogit* pander.coxph* pander.cph*
[11] pander.CrossTable** pander.Date* pander.default* pander.density*
[16] pander.describe* pander.evals* pander.factor* pander.formula* pander.ftable*
[21] pander.function* pander.glm* pander.Glm* pander.gtable* pander.htest*
[26] pander.image* pander.irts* pander.list* pander.lm* pander.lme*
[31] pander.logical* pander.lrm* pander.manova* pander.matrix* pander.microbenchmark*
[36] pander.mtable** pander.nls* pander.NULL* pander.numeric*
[41] pander.ols* pander.orm* pander.polr* pander.POSIXct* pander.POSIXlt*
[46] pander.prcomp* pander.randomForest* pander.rapport* pander.rlm* pander.sessionInfo*
[51] pander.smooth.spline* pander.stat.table* pander.summary.aov* pander.summary.aovlist* pander.summary.glm*
[56] pander.summary.lm* pander.summary.lme* pander.summary.manova* pander.summary.nls* pander.summary.polr*
[61] pander.summary.prcomp* pander.summary.rms* pander.summary.survreg* pander.summary.table* pander.survdiff*
[66] pander.survfit* pander.survreg* pander.table* pander.tabular* pander.ts*
[71] pander.zoo*
If you think that pander lacks support for any other R class(es), please feel free to open a [ticket]( suggesting a new feature or submit [pull request]( and we will be happy to extend the package.
Besides the most basic R object types (vectors, matrices, tables or data frames), list-support might be interesting for you:
> pander(list(a = 1, b = 2, c = table(mtcars$am), x = list(myname = 1, 2), 56))
<%=pander(list(a = 1, b = 2, c = table(mtcars$am), x = list(myname = 1, 2), 56))%>
A nested list can be seen above with a table and all (optional) list names. As a matter of fact, `pander.list` is the default method of `pander` too, when you call it on an unsupported R object class:
> x <- chisq.test(table(mtcars$am, mtcars$gear))
> class(x) <- "I've never heard of!"
> pander(x)
x <- chisq.test(table(mtcars$am, mtcars$gear))
class(x) <- 'I\'ve never heard of!'
So `pander` showed a not known class in an (almost) user-friendly way. And we got some warnings too styled with [Pandoc **footnote**](! If that document is exported to e.g. `HTML` or `pdf`, then the error/warning message could be found on the bottom of the page with a link. *Note*: there were two warnings in the above call - both captured and returned! Well, this is the feature of `Pandoc.brew`, see [below](#brew-to-pandoc).
But the output of different **statistical methods** are tried to be prettyfied. Some the above call normally returns like:
> pander(chisq.test(table(mtcars$am, mtcars$gear)))
<%= chisq.test(table(mtcars$am, mtcars$gear)) %>
A few other examples on the supported R classes:
> pander(t.test(extra ~ group, data = sleep))
<%=t.test(extra ~ group, data = sleep)%>
> ## Dobson (1990) Page 93: Randomized Controlled Trial (examples from: ?glm)
> counts <- c(18, 17, 15, 20, 10, 20, 25, 13, 12)
> outcome <- gl(3, 1, 9)
> treatment <- gl(3, 3)
> m <- glm(counts ~ outcome + treatment, family = poisson())
> pander(m)
counts <- c(18, 17, 15, 20, 10, 20, 25, 13, 12)
outcome <- gl(3, 1, 9)
treatment <- gl(3, 3)
m <- glm(counts ~ outcome + treatment, family = poisson())
> pander(anova(m))
> pander(aov(m))
> pander(prcomp(USArrests))
> pander(density(mtcars$hp))
> ## Don't like scientific notation?
> panderOptions('round', 2)
> pander(density(mtcars$hp))
panderOptions('round', 2)
panderOptions('round', Inf)
And of course tables are formatted (e.g. auto add of line breaks, splitting up tables, hyphenation support or markdown format) based on the user specified [`panderOptions`](#pander-options).
# Creating Pandoc documents
The package is also capable of creating complex Pandoc documents (reports) from **R objects** in multiple ways:
* create somehow a markdown text file (e.g. with `brew`, `knitr` or any scripts of yours, maybe with `Pandoc.brew` - see just [below](#brew-to-pandoc)) and transform that to other formats (like HTML, odt, PDF, docx etc.) with `Pandoc.convert` - similarly to [`pandoc` function in knitr]( Basically this is a wrapper around a [Pandoc]( call, which has not much to do with R actually.
* users might write some reports with literate programming (similar to `knitr`) in a forked version of [brew]( syntax resulting. This means that the user can include R code chunks in a document, and brewing that results in a pretty Pandoc's markdown document and also in a **bunch of other formats** (like HTML, odt, PDF, docx etc.). The great advantage of this [function](#brew-to-pandoc) is that you do not have to transform your R objects to markdown manually, it's all handled automagically.
*Example*: this [``]( is cooked with [`Pandoc.brew`](#brew-to-pandoc) based on [`inst/README.brew`]( and also exported to [HTML]( Details can be found [below](#brew-to-pandoc) or head directly to [examples](#examples).
<!-- endlist -->
* and users might create a report in a live R session by adding some R objects and paragraphs to a `Pandoc` reference class object. Details can be found [below](#live-report-generation).
## Brew to Pandoc
The [brew]( package, which is a templating framework for report generation, has not been updated since 2011, but it's still used in bunch of R projects based on its simple design and useful features in literate programming. For a quick overview, please see the following documents if you are not familiar with `brew`:
* [slides on "Building a reporting sytem with BREW"](
* [learnr blogpost on brew](
**In short**: a `brew` document is a simple text file with some special tags. `Pandoc.brew` uses only two of them (as building on a personalized version of Jeff's really great `brew` function):
* `<<%= '%' %>= ... <%= '%' %>>` stand for running inline R commands as usual,
* `<<%= '%' %>= ... <%= '%' %>>` does pretty much the same but applies `pander` to the returning R object (instead of `cat` like the original `brew` function does). So putting there any R object, it would return in a nice Pandoc's markdown format with all possible error/warning messages etc.
This latter tries to be smart in some ways:
* A code chunk block (R commands between the tags) can return any number of values at any part of the block.
* Plots and images are grabbed in the document, rendered to a `png` file and `pander` method would result in a Pandoc markdown formatted image link. This means that the image would be rendered/shown/included in the exported document.
* All warnings/messages and errors are recorded in the blocks and returned in the document as footnotes or inline messages.
* All heavy R commands (e.g. those taking more then 0.1 sec to evaluate) are [**cached**](#caching) so re`brew`ing a report would not result in a coffee break.
Besides this, the custom `brew` function can do more and also less compared to the original [`brew` package]( First of all, the internal caching mechanism of `brew` has been removed and rewritten for some extra profits besides improved caching.
For example now multiple R expressions can be passed between the `<<%= '%' %>= ... <%= '%' %>>` tags, and not only the text results, but **the evaluated R objects** are also (invisibly) returned in a structured list. This can be really useful while post-processing the results of `brew`. Quick example:
> str(Pandoc.brew(text ='
+ Pi equals to `<<%= '%' %>= pi <%= '%' %>>`.
+ And here are some random data:
+ `<<%= '%' %>= runif(10) <%= '%' %>>`
+ '))
Pi equals to _3.142_.
And here are some random data:
_0.6631_, _0.849_, _0.06986_, _0.3343_, _0.5209_, _0.3471_, _0.866_, _0.05548_, _0.8933_ and _0.2121_
List of 2
$ :List of 4
..$ type : chr "text"
..$ text :List of 2
.. ..$ raw : chr "Pi equals to <%=pi%>.\nAnd here are some random data:\n"
.. ..$ eval: chr "Pi equals to _3.142_.\nAnd here are some random data:\n"
..$ chunks:List of 2
.. ..$ raw : chr "<%=pi%>"
.. ..$ eval: chr "_3.142_"
..$ msg :List of 3
.. ..$ messages: NULL
.. ..$ warnings: NULL
.. ..$ errors : NULL
$ :List of 2
..$ type : chr "block"
..$ robject:List of 6
.. ..$ src : chr "runif(10)"
.. ..$ result: num [1:10] 0.6631 0.849 0.0699 0.3343 0.5209 ...
.. ..$ output: chr "_0.6631_, _0.849_, _0.06986_, _0.3343_, _0.5209_, _0.3471_, _0.866_, _0.05548_, _0.8933_ and _0.2121_"
.. ..$ type : chr "numeric"
.. ..$ msg :List of 3
.. .. ..$ messages: NULL
.. .. ..$ warnings: NULL
.. .. ..$ errors : NULL
.. ..$ stdout: NULL
.. ..- attr(*, "class")= chr "evals"
This document was generated by `Pandoc.brew` based on [`inst/README.brew`]( so the above examples were generated automatically by running:
Pandoc.brew(system.file('README.brew', package = 'pander'))
The output is set to `stdout` by default, which means that the resulting text is written to the R console. But setting the `output` to a text file and running Pandoc on that to create a `HTML`, `odt`, `docx` or other document in one go is also possible. To export a brewed file to other then Pandoc's markdown, please use the `convert` parameter. For example:
text <- paste('# Header',
'What a lovely list:\n<<%= '%' %>= as.list(runif(10)) <%= '%' %>>',
'A wide table:\n<<%= '%' %>= mtcars[1:3, ] <%= '%' %>>',
'And a nice chart:\n\n<<%= '%' %>= plot(1:10) <%= '%' %>>',
sep = '\n')
Pandoc.brew(text = text, output = tempfile(), convert = 'html')
Pandoc.brew(text = text, output = tempfile(), convert = 'pdf')
So to brew this README with all R chunks automatically converted to html, please run:
Pandoc.brew(system.file('README.brew', package='pander'), output = tempfile(), convert = 'html')
### Examples
The package bundles some examples for `Pandoc.brew` to let you check its features pretty fast. These are:
* [minimal.brew](
* [short-code-long-report.brew](
* [graphs.brew](
To `brew` these examples on your machine, try to run the followings commands:
Pandoc.brew(system.file('examples/minimal.brew', package='pander'))
Pandoc.brew(system.file('examples/minimal.brew', package='pander'), output = tempfile(), convert = 'html')
Pandoc.brew(system.file('examples/short-code-long-report.brew', package='pander'))
Pandoc.brew(system.file('examples/short-code-long-report.brew', package='pander'), output = tempfile(), convert = 'html')
Pandoc.brew(system.file('examples/graphs.brew', package='pander'))
Pandoc.brew(system.file('examples/graphs.brew', package='pander'), output = tempfile(), convert = 'html')
For easier access, I have uploaded some exported documents of the above examples as well:
* minimal.brew: [markdown]( [html]( [pdf]( [odt]( [docx](
* short-code-long-report.brew: [markdown]( [html]( [pdf]( [odt]( [docx](
* graphs.brew: [markdown]( [html]( [pdf]( [odt]( [docx](
Please check out `pdf`, `docx`, `odt` and other formats by changing the above `convert` option on your machine, and do not forget to [give some feedback](!
## Live report generation
`pander` package has a special reference class called `Pandoc` which could collect some blocks in a live R session and export the whole document to Pandoc/PDF/HTML etc. Without any serious further explanations, please check out the below (self-commenting) example:
## Initialize a new Pandoc object
myReport <- Pandoc$new()
## Add author, title and date of document
myReport$author <- 'Gergely Daróczi'
myReport$title <- 'Demo'
## Or it could be done while initializing
myReport <- Pandoc$new('Gergely Daróczi', 'Demo')
## Add some free text
myReport$add.paragraph('Hello there, this is a really short tutorial!')
## Add maybe a header for later stuff
myReport$add.paragraph('# Showing some raw R objects below')
## Adding a short matrix
## Or a table with even
myReport$add.paragraph('Hello table:')
myReport$add(table(mtcars$am, mtcars$gear))
## Or a "large" data frame which barely fits on a page
## And a simple linear model with Anova tables
ml <- with(lm(mpg ~ hp + wt), data = mtcars)
## And do some principal component analysis at last
## Sorry, I did not show how Pandoc deals with plots:
## Want to see the report? Just print it:
## Exporting to PDF (default)
## Or to docx in tempdir():
myReport$format <- 'docx'
## You do not want to see the generated report after generation?
myReport$export(open = FALSE)
# Capturing evaluation information with evals
When working on the [rapport package](, I really needed some nifty R function that can evaluate R expression along with capturing errors and warnings. Unfortunately the `evaluate` package had only limited features at that time, as it could not return the raw R object, but only the standard output with messages. So I wrote my own function, and soon some further feature requests arose, like identifying if an R expression results in a plot etc. This section aims to give a quick introduction to the functionality of `evals`, but for more usage/implementation details, please refer to specialized vignette, which can be accessed by `vignette('evals', package='pander')` or available online [here](
But probably it's easier to explain what `evals` can do with a simple example:
> evals('1:10')
<%= paste(capture.output(evals('1:10')), collapse = '\n') %>
So `evals` can evaluate a character vector of R expressions, and it returns a list of captured stuff while running those:
* `src` holds the R expression,
* `result` contains the raw R object as is,
* `output` represents how the R object is printed to the standard output,
* `type` is the `class` of the returned R object,
* `msg` is a list of possible messages captured while running the R expression and
* `stdout` contains if anything was written to the standard output.
Besides capturing this nifty list of important circumstances, `evals` can automatically identify if an R expression is returning anything to a graphical device, and can save the resulting image in a variety of file formats along with some extra options, like applying a custom theme on base, `lattice` or `ggplot2` plots:
> evals('hist(mtcars$hp)')[[1]]$result
<%= evals('hist(mtcars$hp)')[[1]]$result %>
So instead of a captured R object (which would be `NULL` in this situation by the way), we get the path of the image where the plot was saved:
Well, this is not a standard histogram usually returned by the `hist` function, right? As mentioned before, `evals` have some extra features like applying the user defined theme on various plots automatically. Please see the `graphs.brew` example [above](#examples) for further details, or check the related [global options](#evals-options). If you do not like this feature, simply add `evalsOptions('graph.unify`, FALSE)` to your `.Rprofile`.
Further features are described in the [technical docs](, and now I'll only give a brief introduction to another important feature of `evals`.
## Caching
As `pander::evals` is using a **custom caching algorithm** in the means of evaluating R expressions, it might be worthwhile to give a short summary of what is going on in the background when you are running e.g. [`Pandoc.brew`](#brew-to-pandoc), the ["live report generation"](#live-report-generation) engine or `evals` directly:
* Each passed R chunk is `parse`d to single R expressions.
* Each parsed expression's **part** (let it be a function, variable, constant etc.) is evaluated (as `name`) separately to a `list`. This list describes the unique structure *and* the content of the passed R expressions. This has some really great benefits (see below).
* A **hash** is computed of each list element and *cached* too in `pander`'s local environments. This is useful if you are using large data frames, just imagine: the caching algorithm would have to compute the hash for the same data frame each time it's touched! This way the hash is recomputed only if the R object with the given name is changed.
* The list of such R objects is serialized, then an `SHA-1` hash is computed, which is unique and there is no real risk of collision.
* If [`evals`](#evals) can find the cached results in an environment of `pander`'s namespace (if `cache.mode` set to `enviroment` - see [below](#pander-options)) or in a file named to the computed hash (if `ċache.mode` set to `disk`), then it is returned on the spot. *The objects modified/created by the cached code are also updated.*
* Otherwise the call is evaluated and the results and the modified R objects of the environment are optionally saved to cache (e.g. if `cache` is active *and* if the `proc.time()` of the evaluation is higher then it is defined in `cache.time` - see details in [evals' options](#evals-options)).
<a id="in-practice"></a>
As `pander` does not cache based on raw sources of chunks and there is no easy way of enabling/disabling caching on a chunk basis, the users have to live with some *great advantages* and some *minor tricky situations* - which latter cannot be solved theoretically in my opinion, but [I'd love to hear your feedback](
The caching hash is computed based on the structure and **content** of the R commands instead of the used variable names or R expressions, so let us make some POC example to show the **greatest asset**:
x <- mtcars$hp
y <- 1e3
evals('sapply(rep(x, y), mean)')
It took a while, huh? :)
Let us create some custom functions and variables, which are not identical to the above call:
f <- sapply
g <- rep
h <- mean
X <- mtcars$hp * 1
Y <- 1000
And now try to run something like:
evals('f(g(X, Y), h)')
Yes, it was returned from cache!
About the **kickback**:
As `pander` (or rather: `evals`) does not really deal with what is written in the provided sources but rather checks what is **inside that**, there might be some tricky situations where you would expect the cache to work, but it would not. Short example: we are computing and saving to a variable something heavy in a chunk (please run these in a clean R session to avoid conflicts):
evals('x <- sapply(rep(mtcars$hp, 1e3), mean)')
It is cached, just run again, you will see.
But if you would create `x` in your *global environment* with any value (which has nothing to do with the special environment of the report!) **and** `x` was not defined in the report before this call (**and** you had no `x` value in your global environment before), then the content of `x` would result in a new hash for the cache - so caching would not work. E.g.:
x <- 'foobar'
evals('x <- sapply(rep(mtcars$hp, 1e3), mean)')
I really think this is a minor issue (with very special coincidences) which cannot be addressed cleverly - but **could be avoided with some cautions** (e.g. run `Pandoc.brew` in a clean R session like with `Rscript` or [`littler`]( - if you are really afraid of this issue). And after all: you loose nothing, just the cache would not work for that only line and only once in most of the cases.
Other cases when the hash of a call will not match cached hashes:
* a number is replaced by a variable holding the number, e.g.: `evals('1:5')` vs. `x <- 1:5;evals('x')`
* a part of an R object is replaced by a variable holding that, e.g.: `evals('mean(mtcars$hp)')` vs. `x <- mtcars$hp;evals('mean(x)')`
But the e.g. following do work from cache fine:
x <- mtcars$hp
xx <- mtcars$hp*1
<a id='pander-options'></a><a id='panderoptions'></a>
# General options
The package comes with a variety of globally adjustable options, which have an effect on the result of your reports. You can query and update these options with the `panderOptions` function:
* `digits`: numeric (default: `2`) passed to `format`. Can be a vector specifying values for each column (has to be the same length as number of columns). Values for non-numeric columns will be disregarded.
* `decimal.mark`: string (default: `.`) passed to `format`
* `formula.caption.prefix`: string (default: `Formula: `) passed to `pandoc.formula` to be used as caption prefix. Be sure about what you are doing if changing to other than `Formula: ` or `:`.
* `big.mark`: string (default: ``) passed to `format`
* `round`: numeric (default: `Inf`) passed to `round`. Can be a vector specifying values for each column (has to be the same length as number of columns). Values for non-numeric columns will be disregarded.
* `keep.trailing.zeros`: boolean (default: `FALSE`) show or remove trailing zeros in numbers (e.g. in numeric vectors or in columns of tables with numeric values)
* `keep.line.breaks`: boolean (default: `FALSE`) to keep or remove line breaks from cells in a table
* `missing`: string (default: `NA`) to replace missing values in vectors, tables etc.
* `date`: string (default: `'%Y/%m/%d %X'`) passed to `format` when printing dates (`POSIXct` or `POSIXt`)
* ``: `'atx'` or `'setext'` passed to `pandoc.header`
* ``: `'bullet'` (default), `'ordered'` or `'roman'` passed to `pandoc.list`. Please not that this has no effect on `pander` methods.
* ``: `'multiline'`, `'grid'` or `'simple'` passed to `pandoc.table`
* `table.emphasize.rownames`: boolean (default: `TRUE`) if row names should be highlighted
* `table.split.table`: numeric passed to `pandoc.table` and also affects `pander` methods. This option tells `pander` where to split too wide tables. The default value (`80`) suggests the conventional number of characters used in a line, feel free to change (e.g. to `Inf` to disable this feature) if you are not using a VT100 terminal any more :)
* `table.split.cells`: numeric (default: 30) passed to `pandoc.table` and also affects pander methods. This option tells pander where to split too wide cells with line breaks. Set `Inf`` to disable.
* `table.caption.prefix`: string (default: `Table: `) passed to `pandoc.table` to be used as caption prefix. Be sure about what you are doing if changing to other than `Table: ` or `:`.
* `table.continues`: string (default: `Table continues below`) passed to `pandoc.table` to be used as caption for long (split) without a use defined caption
* `table.continues.affix`: string (default: `(continued below)`) passed to `pandoc.table` to be used as an affix concatenated to the user defined caption for long (split) tables
* `table.alignment.default`: string (default: `centre`) that defines the default alignment of cells. Can be `left`, `right` or `centre` that latter can be also spelled as `center`
* `table.alignment.rownames`: string (default: `centre`) that defines the alignment of rownames in tables. Can be `left`, `right` or `centre` that latter can be also spelled as `center`
* `use.hyphening`: boolean (default: `FALSE`) if try to use hyphening when splitting large cells according to table.split.cells. Requires `koRpus` package.
* `evals.messages`: boolean (default: `TRUE`) passed to `evals`' `pander` method specifying if messages should be rendered
* `p.wrap`: a string (default:`'_'`) to wrap vector elements passed to `p` function
* `p.sep`: a string (default: `', '`) with the main separator passed to `p` function
* `p.copula`: a string (default: `'and'`) a string with ending separator passed to `p` function
* `plain.ascii`: boolean (default: FALSE) to define if output should be in plain ascii or not
* `graph.nomargin`: boolean (default: `TRUE`) if trying to keep plots' margins at minimal
* `graph.fontfamily`: string (default: `'sans'`) specifying the font family to be used in images. Please note, that using a custom font on Windows requires `grDevices:::windowsFonts` first.
* `graph.fontcolor`: string (default: `'black'`) specifying the default font color
* `graph.fontsize`: numeric (default: `12`) specifying the *base* font size in pixels. Main title is rendered with `1.2` and labels with `0.8` multiplier.
* `graph.grid`: boolean (default: `TRUE`) if a grid should be added to the plot
* `graph.grid.minor`: boolean (default: `TRUE`) if a miner grid should be also rendered
* `graph.grid.color`: string (default: `'grey'`) specifying the color of the rendered grid
* `graph.grid.lty`: string (default: `'dashed'`) specifying the line type of grid
* `graph.boxes`: boolean (default: `FALSE`) if to render a border around of plot (and e.g. around strip)
* `graph.legend.position`: string (default: `'right'`) specifying the position of the legend: 'top', 'right', 'bottom' or 'left'
* `graph.background`: string (default: `'white'`) specifying the plots main background's color
* `graph.panel.background`: string (default: `'transparent'`) specifying the plot's main panel background. Please *note*, that this option is not supported with `base` graphics.
* `graph.colors`: character vector of default color palette (defaults to a [colorblind theme]( Please *note* that this update work with `base` plots by appending the `col` argument to the call if not set.
* `graph.color.rnd`: boolean (default: `FALSE`) specifying if the palette should be reordered randomly before rendering each plot to get colorful images
* `graph.axis.angle`: numeric (default: `1`) specifying the angle of axes' labels. The available options are based on `par(les)` and sets if the labels should be:
* `1`: parallel to the axis,
* `2`: horizontal,
* `3`: perpendicular to the axis or
* `4`: vertical.
* `graph.symbol`: numeric (default: `1`) specifying a symbol (see the `pch` parameter of `par`)
* ``: boolean (default: `TRUE`) if the results of `pander` should be considered as `asis` in `knitr`. Equals to specifying `results='asis'` in the R chunk, so thus there is no need to do so if set to `TRUE`.
<a id='evals-options'></a><a id='evalsoptions'></a>
Besides localization of numeric formats or the styles of tables, lists and plots, there are some technical options as well, which would effect e.g. [caching](#caching) or the format of rendered image files. You can query/update those with the `evalsOptions` function as the main backend of `pander` calls is a custom evaluation function called [`evals`](#evals).
The list of possible options are:
* `parse`: if `TRUE` the provided `txt` elements would be merged into one string and parsed to logical chunks. This is useful if you would want to get separate results of your code parts - not just the last returned value, but you are passing the whole script in one string. To manually lock lines to each other (e.g. calling a `plot` and on next line adding an `abline` or `text` to it), use a plus char (`+`) at the beginning of each line which should be evaluated with the previous one(s). If set to `FALSE`, [`evals`](#evals) would not try to parse R code, it would get evaluated in separate runs - as provided. Please see the documentation of [`evals`](#evals).
* `cache`: [caching](#caching) the result of R calls if set to `TRUE`
* `cache.mode`: cached results could be stored in an `environment` in _current_ R session or let it be permanent on `disk`.
* `cache.dir`: path to a directory holding cache files if `cache.mode` set to `disk`. Default set to `.cache` in current working directory.
* `cache.time`: number of seconds to limit caching based on `proc.time`. If set to `0`, all R commands, if set to `Inf`, none is cached (despite the `cache` parameter).
* `cache.copy.images`: copy images to new file names if an image is returned from the *disk* cache? If set to `FALSE` (default), the cached path would be returned.
* `classes`: a vector or list of classes which should be returned. If set to `NULL` (by default) all R objects will be returned.
* `hooks`: list of hooks to be run for given classes in the form of `list(class = fn)`. If you would also specify some parameters of the function, a list should be provided in the form of `list(fn, param1, param2=NULL)` etc. So the hooks would become `list(class1=list(fn, param1, param2=NULL), ...)`. See example of [`evals`](#evals) for more details. A default hook can be specified too by setting the class to `'default'`. This can be handy if you do not want to define separate methods/functions to each possible class, but automatically apply the default hook to all classes not mentioned in the list. You may also specify only one element in the list like: `hooks=list('default' = pander_return)`. Please note, that nor error/warning messages, nor stdout is captured (so: updated) while running hooks!
* `length`: any R object exceeding the specified length will not be returned. The default value (`Inf`) does not filter out any R objects.
* `output`: a character vector of required returned values. This might be useful if you are only interested in the `result`, and do not want to save/see e.g. `messages` or `print`ed `output`. See examples of [`evals`](#evals).
* `graph.unify`: should `evals` try to unify the style of (`base`, `lattice` and `ggplot2`) plots? If set to `TRUE`, some `panderOptions()` would apply. By default this is disabled not to freak out useRs :)
* ``: set the file name of saved plots which is `%s` by default. A simple character string might be provided where `%d` would be replaced by the index of the generating `txt` source, `%n` with an incremented integer in `graph.dir` with similar file names and `%t` by some unique random characters. When used in a `brew` file, `%i` is also available which would be replaced by the chunk number.
* `graph.dir`: path to a directory where to place generated images. If the directory does not exist, [`evals`](#evals) try to create that. Default set to `plots` in current working directory.
* `graph.output`: set the required file format of saved plots. Currently it could be any of `grDevices`: `png`, `bmp`, `jpeg`, `jpg`, `tiff`, `svg` or `pdf`. Set to `NA` not to save plots at all and tweak that setting with `capture.plot()` on demand.
* `width`: width of generated plot in pixels for even vector formats
* `height`: height of generated plot in pixels for even vector formats
* `res`: nominal resolution in `ppi`. The height and width of vector images will be calculated based in this.
* `hi.res`: generate high resolution plots also? If set to `TRUE`, each R code parts resulting an image would be run twice.
* `hi.res.width`: width of generated high resolution plot in pixels for even vector formats. The `height` and `res` of high resolution image is automatically computed based on the above options to preserve original plot aspect ratio.
* `graph.env`: save the environments in which plots were generated to distinct files (based on ``) with `env` extension?
* `graph.recordplot`: save the plot via `recordPlot` to distinct files (based on ``) with `recodplot` extension?
* `graph.RDS` save the raw R object returned (usually with `lattice` or `ggplot2`) while generating the plots to distinct files (based on ``) with `RDS` extension?
* `log`: `NULL` or an optionally passed *logger name* from `futile.logger` to record all info, trace, debug and error messages.
# Difference from other rendering packages
How does `pander` differ from Sweave, brew, knitr, R2HTML and the other tools of literate programming? First of all `pander` can be used as a helper with any other literate programming solution, so **you can call `pander` inside of `knitr` chunks**.
But if you stick with `pander`'s literate programming engine, then there's not much need for calling `ascii`, `xtable`, `Hmisc`, `tables` etc. or even `pander` in the R command chunks to **transform R objects** into markdown, HTML, tex etc. as `Pandoc.brew` automatically results in Pandoc's markdown, which can be converted to almost any text document format. Conversion can be done automatically after calling `pander` reporting functions ([Pander.brew](#brew-to-pandoc) or [Pandoc](#live-report-generation)).
Based on the fact that `pander` transforms R objects into markdown, **no "traditional" R console output is shown** in the resulting document (nor in markdown, nor in exported docs), but **all R objects are transformed to tables, list etc**. Well, there is an option (`show.src`) to show the original R commands before the formatted output, and `pander` calls can be also easily tweaked to return the printed version of the R objects - if you would need that in some strange situation - like writing an R tutorial. But really think that nor R code, nor raw R results have anything to do with an exported report.
Of course **all warnings, messages and errors are captured** while evaluating R expressions just like `stdout` besides the **raw R objects**. So the resulting report also includes the raw R objects for further edits if needed - which is a very unique feature.
**Graphs and plots are automatically identified** in code chunks and saved to disk in a `png` file linked in the resulting document. This means that if you create a report (e.g. `brew` a text file) and export it to PDF/docx etc. all the plots/images would be there. There are some parameters to specify the resolution of the image and also the type (e.g. `jpg`, `svg` or `pdf`) besides a **wide variety of [theme options](#pander-options)**. About the latter, please check the `graphs.brew` example [above](#examples).
And `pander` uses its built-in (IMHO quite decent) [**caching**](#caching) engine. This means that if the evaluation of some R commands takes too long time (which can be set by option/parameter), then the results are saved in a file and returned from there on next similar R code's evaluation. This caching algorithm tries to be smart, as it not only checks the passed R sources, but the content of all variables and functions, and saves the hash of those. This is a quite secure way of caching (see details [above](#caching)), but if you would encounter any issues, just switch off the cache. I've not seen any issues for years :)
I have created some simple LISP functions which would be handy if you are using the best damn IDE for R. These functions and default key-bindings are [shipped with the package](, feel free to personalize.
As time passed these small functions grew heavier (with my Emacs knowledge) so I ended up with a small library:
## pander-mode
I am currently working on `pander-mode` which is a small *minor-mode* for Emacs. There are a few (but useful) functions with default keybindings:
* `pander-brew` (`C-c p b`): Run `Pandoc.brew` on current buffer or region (if mark is active), show results in *ess-output* and (optionally) copy results to clipboard while setting working directory to `tempdir()` temporary.
* `pander-brew-export` (`C-c p B`): Run `Pandoc.brew` on current buffer or region (if mark is active) and export results to specified (auto-complete in minibuffer) format. Also tries to open exported document.
* `pander-eval` (`C-c p e`): Run `pander` on (automatically evaluated) region *or* current chunk (if marker is not set), show results (of last returned R object) in `*ess-output*` and (optionally) copy those to clipboard while setting working directory to `tempdir()` temporary.
Few options of `pander-mode`: `M-x customize-group pander`
* `pander-clipboard`: If non-nil then the result of `pander-*` functions would be copied to clipboard.
* `pander-show-source`: If non-nil then the source of R commands would also show up in generated documents while running 'pander-eval'. This would not affect `brew` functions ATM.
To use this small lib, just type: `M-x pander-mode` on any document. It might be useful to add a hook to `markdown-mode` if you find this useful.
<script type="text/javascript">
$(document).ready(function() {
$('img[src=""]').css('border', 'none').css('padding', '0px').parent().parent().css('text-align', 'justify');
$('img[src=""]').css('border', 'none').css('padding', '0px').parent().parent().css('text-align', 'justify');
$('nav').css('height', '100%');
<a href=""><img style="position: fixed; top: -5px; right: -5px; border: 0;" src="" data-canonical-src=""></a>