First off: Excellent package, I just discovered today and I am already using it to mass generate EDAs for a bunch of inherited datasets :-)
Now for the suggested changes.
In the line:
| writer("output: pdf_document") |
The YAML generated just uses the default engine, which is usually pdflatex, but that engine cannot handle Unicode characters, so there might be at least three options:
- Autoselect
xelatex or luatex, over pdflatex if any of those is available, so the YAML will look something like:
pdf_document:
latex_engine: xelatex
Allow for a parameter or an option() to specify the latex engine
Document that creating the file _output.yaml (or _output.yml) in the output dir, will override the engine definition (see: https://bookdown.org/yihui/rmarkdown/html-document.html#shared-options)
I run into this issue with data that contained unicode chars, and ended up using option (3), which might not be too well known.
From the API user point of view, options (1) and (2) (not mutually exclusive) would be smoother.
First off: Excellent package, I just discovered today and I am already using it to mass generate EDAs for a bunch of inherited datasets :-)
Now for the suggested changes.
In the line:
dataReporter/R/makeDataReport.R
Line 635 in d29e28f
The YAML generated just uses the default engine, which is usually
pdflatex, but that engine cannot handle Unicode characters, so there might be at least three options:xelatexorluatex, overpdflatexif any of those is available, so the YAML will look something like:Allow for a parameter or an
option()to specify the latex engineDocument that creating the file
_output.yaml(or_output.yml) in the output dir, will override the engine definition (see: https://bookdown.org/yihui/rmarkdown/html-document.html#shared-options)I run into this issue with data that contained unicode chars, and ended up using option (3), which might not be too well known.
From the API user point of view, options (1) and (2) (not mutually exclusive) would be smoother.