Thanks. Here's what I found four years ago:
Buried in help(rmarkdown) lies the secret sauce to pass to pandoc the command line arguments that will sneak an invisible filter through which will tickle its imput to pummel the raw output of xtable into presentable \LaTeX and, thus, ultimately, into polished tables that don't require hand tweaking.
In the forepart yaml, add
where style1 is a program that reads from stdin and writes to stdout, parsing the output of pandoc and feeding it back into pandoc for further rendering.
pandoc's API exposes a serialization of the abstract syntax tree (AST) that it uses to internally represent the source document for transformation into the target document and allows free access to anything in the
yaml forematter for use in a document template, the functionality to directly access the
yaml fields for anything else is suppressed. Unless you want to fork the pandoc project and refactor the code (in Haskell) to permit this, keeping your programmatic edits in the forematter is not in the cards, at least to the dealer at this table.
I was able to tweak the
yaml header with
where style1 is a Haskell program that reads from stdin and writes to stdout, parsing the output of
pandoc and feeding it back into
pandoc for further rendering.
My requirement was for formatting. My recollection is that my plan if I wanted to draw on arbitrary
yaml was to run the *.Rmd file through a pre-processor parser to create chunks of
R code based on the header.
Things might have changed in the past four years. While I've keep current with both
pandoc, I haven't been specifically monitoring this issue. Looking at the latest
help(rmarkdown) there doesn't seem to be any suggestion of grabbing arbitrary
yaml. I'd have to re-read the current
pandoc source code to retract my earlier conclusion on the limitation I described. But I'm a bit rusty.