-
Notifications
You must be signed in to change notification settings - Fork 12
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
Comments
You’re gonna hate this because this time it would definitely break compatibility but hear me out. Rather than adding yet another option ( 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 # 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. |
@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 done. |
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! |
It indeed would be a very welcomed addition! I have too many other projects
to work on so I doubt I'll be implementing it, but I will very happily
accept a pull request if anyone wants to work in it.
…On Aug 9, 2017 9:42 AM, "jfieberg" ***@***.***> wrote:
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!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#10 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AA6IFI3YjZDF1qA-CylOjcIMPF-LUzKqks5sWbdGgaJpZM4KPIgv>
.
|
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 ?
The text was updated successfully, but these errors were encountered: