Skip to content

Support PDF output #10

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
daattali opened this issue Oct 5, 2016 · 6 comments
Open

Support PDF output #10

daattali opened this issue Oct 5, 2016 · 6 comments

Comments

@daattali
Copy link
Collaborator

daattali commented Oct 5, 2016

Outputting to PDF is not currently supported because it is not a knitr feature (it's usually done using rmarkdown::render().

However, it seems like many people associate PDF output to knitr because of the "knit" button in RStudio, and many people have wondered why you can't ezknit into PDF.

@ttimbers asked about this in the package review, @klmr mentioned this in issue #8 , and @PedramNavid recently mentioned this in a high profile Twitter convo

Perhaps it's time to look into somehow supporting PDF as an output. I'm not sure what the best way would be: should we just add an extra parameter that lets you specify you want PDF output, and if that's set then the flow would be: input Rmd --> ezknit to md --> render to pdf ?

@klmr
Copy link
Collaborator

klmr commented Oct 6, 2016

You’re gonna hate this because this time it would definitely break compatibility but hear me out.

Rather than adding yet another option (keep_pdf?), why not rigorously decouple knitting and downstream document generation? In other words, have ezknit/ezspin in the first instance generate a Markdown document — after all, this is what knitr does, and this always needs to happen, regardless of downstream target.

And then a second function — which doesn’t even need to be part of this package — generates the target format from that, using whatever means necessary (pandoc, you-name-it). This is the most consistent and simple interface, and it reduces dependencies for ezknitr (knitr is enough, no rmarkdown/pandoc/pdflatex needed).

Alternatively this process can be simplified at the cost of a slight API deterioration by adding a postprocess argument to ezknit/ezspin (and removing the now-redundant keep_html). This argument accepts a function that transforms the Markdown document into something else, similarly to the output_format in rmarkdown::render. Then ezknitr can be used as follows:

# Generates report/test.md
ezknit('code/test.rmd', '.', 'report', 'fig')

# Generates report/test.{md,html}
ezknit('code/test.rmd', '.', 'report', 'fig', postprocess = html_document)

# Generates report/test.{md,tex,pdf}
ezknit('code/test.rmd', '.', 'report', 'fig', postprocess = pdf_document)

# Generates report/test.html
ezknit('code/test.rmd', '.', 'report', 'fig', postprocess = html_document, keep_md = FALSE)

Since this breaks backwards compatibility, and I honestly cannot see a clean way of implementing this without making a mess of the API, maybe it’s time for ezknitr-2.0.0.

@daattali
Copy link
Collaborator Author

daattali commented Oct 6, 2016

@klmr I was thinking the same thing. I don't like the first option as much, but I was thinking about something along the lines of the second option, that will include breaking changes. I don't think breaking changes are too horrible, especially given the fact that most ezknitr code is probably not inside packages and therefore there only direct users of ezknitr will have to adapt.

I suppose this is very related to #8

@daattali
Copy link
Collaborator Author

daattali commented Oct 6, 2016

@noamross @karthik can someone please add @klmr as a collaborator on this repo? He's been a user of and had good ideas about this package from the very first day, he should be able to modify it if he needs to

@karthik
Copy link
Member

karthik commented Oct 6, 2016

@daattali done.

@jfieberg
Copy link

jfieberg commented Aug 9, 2017

I am a big fan of the ezknitr package (and, in particular, ezspin). Prior to discovering it, I used to implement all sorts of clunky work arounds (e.g. using file,copy). Curious if you plan to implement the post-process option above? I think this would be a welcome addition!

@daattali
Copy link
Collaborator Author

daattali commented Aug 9, 2017 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants