-
-
Notifications
You must be signed in to change notification settings - Fork 878
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
Encoding issue during knitting on Windows #1944
Comments
And I think this is known and related to old encoding issues : r-lib/evaluate#59 and r-lib/evaluate#66 There was a very close one that had a fix but it seems it did not fix this completly r-lib/evaluate#74 |
Yes, it's a known issue: r-lib/evaluate#59. Unfortunately, there's nothing we could do about it, except waiting for the UTF-8 build of R is officially available: https://developer.r-project.org/Blog/public/2020/07/30/windows/utf-8-build-of-r-and-cran-packages/index.html Actually there could a workaround but it depends on if your Windows supports the locale. That is, you can call |
R 4.2.0 is coming in about a month: https://developer.r-project.org I guess the current R-devel already works: https://cloud.r-project.org/bin/windows/base/rdevel.html If not, we can reopen this issue and investigate further. |
This old thread has been automatically locked. If you think you have found something related to this, please open a new issue by following the issue guide (https://yihui.org/issue/), and link to this old issue if necessary. |
Initial Context
This was reported by @thomasp85 while working on fonts support for graphic design.
Here are the initial issues
leading to this graphs when executed in the IDE in R console
but this in the knitted document
Issues with encoding in knitr
Using a
test.Rmd
file encoded in UTF-8 with this contentit will lead to a different result in the IDE when executing chunk (which leads to code being executed in the R console)
than when knitted
knitr::knit("test.Rmd")
resulting inIt seems that there are some conversions happening during the evaluation process that leads to incorrect support of those UTF-8 strings
@yihui you may already know about this limitations regarding encoding. Are we missing something ?
The text was updated successfully, but these errors were encountered: