-
-
Notifications
You must be signed in to change notification settings - Fork 975
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
Differing output when providing output_file
argument to render()
#2264
Comments
@grimbough thanks for the report. Can you explain the hack done for the soul package ? having backslash seems the way Pandoc transforms it
Also using I would like to understand what exactly is needed for this soul package. That being said, I don't yet understand why a post processor would not apply if an extension is set to |
The addition of the soul package to the BiocStyle The comment on the soul patch reads "# substitute all control spaces "\ " in \texttt by regular spaces" and the actual patch code can be found in the
I think this isn't a problem because
The problem in this case is not that the post processor doesn't get applied when we set a file extension, it's more that unless the file extension is I the case where we don't set a file extension to the Lines 487 to 491 in 0af6b35
|
Thanks for your feedback. I got some hint yesterday in my bug hunt but did not share because it was not ended. I found the part of the code that make the post processing not run correctly Lines 974 to 981 in 0af6b35
The code you shared above is trying to determine what should be the output file extension when none is asked (most of the time
The post processor will be run after on the output file being a pdf. Until recently,
Lines 974 to 981 in 0af6b35
and then in Lines 1001 to 1006 in 0af6b35
From what I understand, With the current way rmarkdown is working, In a way, I don't think all of this is expected and we will look to improve that. I need to discuss with @yihui to understand the historical behavior and see how we can change that. Personally, I did not have any idea of this issue - thanks for reporting ! That is an odd bug - it took me time to understand. |
About that, I tried to reproduce the initial BiocStyle is trying to solve with it patch by using
This will redefine the the I was just curious to understand. I don't know if there is anything else that can be done to be compatible with control spaces. |
Thanks for the feedback. I agree it's an odd bug, and also took me quite some time to pin down the behaviour. I was reluctant to report anything until I was sure it wasn't BiocStyle doing something unsupported. Reading through I think we've come to exactly the same conclusions about what's happening, so that's encouraging! From my point of view there no problem if it takes a while to fix - that soul patch has been in BiocStyle for 5 years and it's only been reported now, so I guess providing a non-default output file name doesn't occur very often for our users, and we have the "no extension" work around anyway. I guess there's something philosophical about the choice of output file if someone does something weird like |
I can understand - it is not like that with all formats. Somehow in all relies on what
This Thanks a lot for this discussion ! We'll work on rmarkdown early next year so we'll probably modify this. |
Checklist
When filing a bug report, please check the boxes below to confirm that you have provided us with the information we need. Have you:
formatted your issue so it is easier for us to read?
included a minimal, self-contained, and reproducible example?
pasted the output from
xfun::session_info('rmarkdown')
in your issue?upgraded all your packages to their latest versions (including your versions of R, the RStudio IDE, and relevant R packages)?
installed and tested your bug with the development version of the rmarkdown package using
remotes::install_github("rstudio/rmarkdown")
?This issue concerns the BiocStyle package and producing a PDF vignette from R Markdown. This issue has initially been tracked in Bioconductor/BiocStyle#93 I'm happy to incorporate necessary changes into BiocStyle, but wanted to report the unexpected behaviour here.
Consider the following minimal Rmd file (referred to as
test.Rmd
below) using theBiocStyle::pdf_document
output format:However it fails when supply an
output_file
argument. (In the example below I've usedtest1.pdf
to distinguish between files, but it fails with the same error even if you use is the same as the default i.e.test.pdf
).Examining the two TeX files produced, the line containing the inline code differs, and seems to have some escaped spaces in the version that fails to compile. The two lines are show below for comparison.
Normally BiocStyle is aware of this issue and attempts to remove the escaped spaces before Latex is called. However this patch is not applied when we specify the name of an output file with ".pdf" extension.
I believe the difference in output starts with the following code block:
rmarkdown/R/render.R
Lines 487 to 491 in 0af6b35
In our example where
output_file
is unspecified then it will be assignedtest.tex
(the value ofoutput_auto
) with the file extension reflecting the definition inoutput_format$pandoc$ext
. When we provideoutput_file = "test1.pdf"
as an argument it obviously has ".pdf" as the extension.This then affects the following code block, which is executed only in the case where we've specified
output_file = "test1.pdf"
:rmarkdown/R/render.R
Lines 974 to 982 in 0af6b35
In the case of
output_file = "test1.pdf"
the latex compilation is carried out immediately at this step vialatexmk()
and fails due to something in the BiocStyle template. However whenoutput_file
has a ".tex" extension compilation is deferred and carried out as part ofoutput_format$post_processor
, which also patches the template issues. This is based on the technique used in bookdown.Hopefully the above makes sense! I'm not sure if we're doing something unsupported in BiocStyle but it seems the crux of this issue is that specifying the output file name will override the setting defined by our
output_format$pandoc
, and cause latex compilation to happen earlier than it otherwise would. I wanted to check whether this is the expected behaviour. I believe the issue is also present (but silently works) if you useoutput_format = bookdown::pdf_document2
. Therelatexmk()
will be called twice - once inrender()
and once in theoutput_format$post_processor.
with the second overwriting the first.The text was updated successfully, but these errors were encountered: