Add knit_print method for dml_pptx

[noamross]

This is my first crack at addresssing #26. Not sure it's ready to merge but it works. Still requires some more robust testing. I'm also unsure whether dml() is the best function name, but it is short!

This requires development pandoc (>=2.4), as well as development rmarkdown, due to a PR I sent there making it possible to lookup the template pptx from within the Rmd file.

The method will look up placeholder locations and use these for the dimensions of the printed graph, but the user can override them to place the graph anywhere on the slide. Some internal functions are memoised so as to avoid creating/opening the reference pptx every time dimensions are needed.

Raster plots are not supported, and I don't think it's possible to do so without a post_processor approach. It would be useful to do this, in an officer_pptx rmarkdown type or maybe as a PR to rmarkdown::powerpoint_document() It would allow users to use the mechanism here to place static images anywhere on the slide they would like, as well. I think the best way to implement would be to put the post-processing requirements in the knit_print metadata, as htmlwidgets do.

[noamross]

One other thing I'll note is that I have made no attempt to set correct id numbers for the DrawingML objects, yet somehow it works, even when I have multiple dml() plots on a single slide. (A Test Rmd is here, btw.) Is Powerpoint just robust to this? How might I test this breaking something?

[davidgohel]

@noamross thanks, that's really cool.

It works well on my machine!

Raster plots are not supported, and I don't think it's possible to do so without a post_processor approach. It would be useful to do this, in an officer_pptx rmarkdown type or maybe as a PR to rmarkdown::powerpoint_document() It would allow users to use the mechanism here to place static images anywhere on the slide they would like, as well. I think the best way to implement would be to put the post-processing requirements in the knit_print metadata, as htmlwidgets do.

Yes, I do agree. Do you know if we can get the slide index (the active one) in the knit_print method? Being able to specify a post_processor function argument in powerpoint_document would be great but useless if we can not know which relationship file should be modified.

I don't want to impose rmarkdown (>= 1.10.14), I know organisations where it would generate lot of issues. I am wondering if it should not go in another package (worded for example, that then should be renamed).

PS: What do you mean by knit_print metadata, as htmlwidgets do?

[noamross]

I agree that maybe this should go into another package that focuses on office-Rmarkdown workflow, such as worded. I think in any case this is going to have to wait a while for general release. In addition to requiring rmarkdown > 1.10.14, it requires development pandoc, and most people only use the pandoc version bundled with the latest RStudio release. For now I'll change it so that requirement is imposed in the function, rather than the package level.

I'll look into the getting the slide index in knit_print. I'm not sure if one can - we might need to just leave some other marker for a post-processor to walk through the document and find the appropriate slide index.

P.S. knit_print() let's you add information to a metadata object that accumulates entries as the document is knit, which is then accessible by the post-processor. More info here. Htmlwidgets use this so that when they print they register their javascript dependencies in the metadata, and then rmarkdown collates all those dependencies and inserts them into the document header in the post-processor. We could do something similar here, registering the slide number and raster file in the metadata when printing and then passing these to the post-processor.