Live preview not working with rmd using `bookdown::render_book`
Consider the following rmd using bookdown::render_book provided in #855:
---
output: bookdown::gitbook
knit: bookdown::render_book
---
# Test
Para.
---
# Next
Live preview does not work with such document:
processing file: main.Rmd
|
| | 0%
|
|......................................................................| 100%
ordinary text without R code
output file: /Users/ken/.vscode-R/tmp/main.knit.md
Error in relativeTo(basepath, dir) :
The path /Users/ken/Workspaces/test/rbook/libs/header-attrs-2.11 does not appear to be a descendant of /Users/ken/.vscode-R/tmp/
Calls: cat ... html_dependencies_as_string -> lapply -> FUN -> relativeTo
Backtrace:
1: stop("The path ", file, " does not appear to be a descendant of ",
2: relativeTo(basepath, dir)
3: FUN(X[[i]], ...)
4: lapply(dependencies, makeDependencyRelative, basepath = output_dir,
5: html_dependencies_as_string(dependencies, lib_dir, output_dir)
6: as_tmpfile(html_dependencies_as_string(dependencies, lib_dir,
7: pandoc_html_extras_args(extras, self_contained, lib_dir, output_dir)
8: base(...)
9: output_format$pre_processor(front_matter, input, runtime, knit_meta,
10: rmarkdown::render(file_path, output_format = set_html, output_file = output_file_loc,
11: cat(lim, rmarkdown::render(file_path, output_format = set_html,
Execution halted
[VSC-R] main.Rmd process exited with exit code 1
Looks like rendering to ~/.vscode-R/tmp makes the paths inconsistent.
I meet the same problem . shows : 'Error in relativeTo(basepath, dir) : The path $WORKDIR/libs/header-attrs-2.9 does not appear to be a descendant of $HOME/.vscode-R/tmp/ Calls: cat ... html_dependencies_as_string -> lapply -> FUN -> relativeTo'
It looks like this is also an issue with the bookdown format and outputs that use libs in general. We can get around this by using output_options = list(self_contained = TRUE. However, we run into another problem -- bookdown is not respecting the output_dir argument. So no matter what we specify, the files will always be knit to the working directory, leading to another error
I am also running into this issue as well trying to use the revealjs package which is a Rmd wrapper around the reveal.js presentation framework. The output is rendered as if it were a plain Markdown file. However, it does work correctly if I directly invoke rmarkdown::render from the console.
I tried to add self_contained = true as per https://github.com/rstudio/revealjs#document-dependencies, to no avail.
- Is there any workaround without touching the extension itself to modify
output_options?
this is also an issue with the bookdown format and outputs that use libs in general
- What is the blocker for this, if
rmarkdown::renderjust works?
I am very new to R and Rmd, and sorry if any of these questions sounds nonsensical.
Hi @SuibianP ,
Thank you for the comment. It's been a little while since I looked at this so I may need a refresher.
I haven't used revealjs before so I'll have to look into the specific reason it doesn't work. If it's a lib folder problem like bookdown, it's because our preview mechanism generates an html file in a temporary folder, and expects the file to work as-is. An issue I ran into with bookdown was that there was no way of telling it where to put the lib folder that worked at the time = file can't knit
Custom knit and rmarkdown::render don't run into this problem because we don't try to hide the knit files in a temporary folder.
Hi @ElianHugh,
Thanks for the reply. I tried to diff the pandoc command lines and here is what I think makes the difference,
--to
-html4
+revealjs
--from
-markdown+autolink_bare_uris+tex_math_single_backslash
+markdown+autolink_bare_uris+tex_math_single_backslash-implicit_figures
Seems that the output key in the front matter (revealjs::revealjs_presentation) is not respected?
The relevant snippet seems to be https://github.com/rstudio/revealjs/blob/e1893aed9df79d26db48538ace56cc0d55ae2f0c/R/revealjs_presentation.R#L319.
Is it that the pandoc options not respected for render_site?
This issue is stale because it has been open for 365 days with no activity.
This issue was closed because it has been inactive for 14 days since being marked as stale.