2

Update 3: I seem to have fixed the problem via close coordination of setting fileEncoding parameters and using the function slidify(file.Rmd, encoding="UTF-8"), the links above will help, as including the fix-encode branch of slidify was required in addition to slidify with install_github('ramnathv/slidify@fix_encode'), but it should be included in the main set probably very soon. I'll keep this here for archival purposes. Can't say the exact thing that fixed it, but the problem was probably due to input files being of different encoding than the script file, as the default encodings seemed to cause some problems. I'm still somewhat unsure of what exactly happened, but I am grateful and amazed at Ramnathv, the maintainer of slidify, in actively participating in all these discussions. The story of this fix is also in the links above.

I'll keep this post online just for archival purposes, perhaps someone else will end up in a very similar situation to where I was at.

Update 2: There have been issues with encoding with slidify before, some of which have been solved, more info in these links: https://github.com/ramnathv/slidify/issues/377, http://kohske.github.io/ESTRELA/201412/index.html, https://github.com/ramnathv/slidify/issues/373, https://github.com/Koalha/landslide/blob/master/index.Rmd

Update: The issue seems to occur when opening a file that contains utf-8 characters. Writing r "õ,ä,ü" within code brackets in text seems to work fine, but when opening a file with variables containing utf-8 characters causes problems in the script. These problems don't occur when using knitr to compile to html5. Anyone know what the differences between the two could be?

key <- read.csv("key1.csv", header = TRUE, sep = ";", 
        quote = "\"", dec = ".", fill = TRUE, comment.char = "")
print(key)

Adding and encoding parameter, or fileEncoding did not seem to help, html knitr doesn't seem to need it.

Edit: Still not solved, but I may be closer to the the cause of the situation. It turns out that while the Rmd itself was saved as UTF-8, many of the datasets used still reverted to ANSI on storage. Possibly an issue of mixed file types then. Best case slidify(file.Rmd, encoding="UTF-8") seems to compile the .md with characters correctly encoded, however during data processing errors due to encoding mismatches have happened already. These issues have not occurred on regular knitr Rmd to html conversions.

I'm working on converting an html Rmarkdown document into ioslides type Rmarkdown document, and I've stumbled onto an unexpected issue. The document works with no issues on regular knitr construction, but seems to run into character encoding issues with exactly the same code, environment and directory in slidify.

Namely, that knitr seems to crash when encountering a variable that contains a non-latin character (such as ä,ü,ö) and when it output text contains these characters they are replaced with "?" rectangles.

I am using the setup based on Claas-Thido Pfaff's example: http://cpfaff.github.io/reproducibility/. I haven't yet found a place where it would specify or alter the locale (as exactly the same document works fine with html output.

---
title       : Reproducible Reports
subtitle    : With R, Knitr, LaTeX and Markdown 
author      : Claas-Thido Pfaff 
job         : http://cpfaff.github.io/reproducibility
framework   : io2012        # {io2012, html5slides, shower, dzslides, ...}
highlighter : highlight.js  # {highlight.js, prettify, highlight}
hitheme     : tomorrow      # 
widgets     : [mathjax, bootstrap]            # {mathjax, quiz, bootstrap}
mode        : selfcontained # {standalone, draft}
knit        : slidify::knit2slides
github      :
  author    : changed
  repo      : reproducibility
---

```{r echo = FALSE, include = F, eval = T}
require(knitr)
hook_source_def = knit_hooks$get('source')
knit_hooks$set(source = function(x, options){
  if (!is.null(options$verbatim) && options$verbatim){
    opts = gsub(",\\s*verbatim\\s*=\\s*TRUE\\s*", "", options$params.src)
    bef = sprintf('\n\n    ```{r %s}\n', opts, "\n")
    stringr::str_c(bef, paste(knitr:::indent_block(x, "    "), collapse = '\n'), "\n    ```\n")
  } else {
     hook_source_def(x, options)
  }
})

require(ggplot2)
```

Any ideas? Thanks!

sinsuren
  • 1,745
  • 2
  • 23
  • 26
puslet88
  • 1,288
  • 15
  • 25
  • Try to set locale in your script as in http://stackoverflow.com/questions/20577764/set-locale-to-system-default-utf-8/22927566#22927566. If you find the link helpful, you may upvote it. – Sathish Mar 30 '15 at 16:52
  • to get your current locale, use this function: Sys.getlocale() – Sathish Mar 30 '15 at 16:53
  • once you know your current locale, you can revert back and forth with the one suggested in the above link – Sathish Mar 30 '15 at 16:53
  • Thanks a lot for the comment, I've tried setting and getting my locale in multiple locations within the script, unfortunately it makes no difference, and seems to be the correct one all the way through. The same locale that works with regular knitr to html5 output. – puslet88 Mar 30 '15 at 17:06
  • Try the answer posted here. http://stackoverflow.com/questions/22876746/how-to-read-data-in-utf-8-format-in-r/22927136#22927136. Again, if you find it helpful, please upvote it. Thanks – Sathish Mar 30 '15 at 17:08
  • The second link explains how to read unicode data using read.table function with encoding="UTF-8" argument. – Sathish Mar 30 '15 at 17:10
  • If you are able to read in unicode data using the answer posted in the second link, then you need to convert it to character format in order to view it. For example print(as.character(key[1,1])). – Sathish Mar 30 '15 at 17:17
  • Thanks for the help, I had a look, but didn't get these to help me. I'm still confused as everything works perfect with regular knitr to html, however slidify can't successfully work with non-latin variables. I've discovered that some data sources are a different encoding from the .Rmd file. Possibly that causes extra complications. – puslet88 Mar 30 '15 at 21:15
  • Sorry, this problem is not solved yet for you. I thought you had issues with reading unicode data (utf8) as described in your question, but have no idea about the package slidify. I personally, do not have any experience with this pkg... hope you find an answer soon. – Sathish Mar 31 '15 at 05:42
  • Thanks for the help @Sathish, slidify seems to have some extra requirements for the code that other people have worked to solve too. I've finally got it to work via the function `slidify(file.Rmd, encoding="UTF-8")` and carefully setting the fileEncoding parameters on import, as rstudio used different settings than the file. – puslet88 Mar 31 '15 at 19:53
  • @puslet88: If you have solved the problem yourself, you should post the solution *as an answer*, not as comments or edits to the question. You can then accept your own answer after a waiting period of 48 hours. – Nisse Engström Oct 22 '16 at 09:00

1 Answers1

0

As recommended by @Nisse-Engström, I post the final solution as an answer instead of an update for the original question. I believe the fix encode should be integrated into the main slidify package by now.

I seem to have fixed the problem via close coordination of setting fileEncoding parameters and using the function slidify(file.Rmd, encoding="UTF-8"), the links above will help, as including the fix-encode branch of slidify was required in addition to slidify with install_github('ramnathv/slidify@fix_encode'), but it should be included in the main set probably very soon. I'll keep this here for archival purposes. Can't say the exact thing that fixed it, but the problem was probably due to input files being of different encoding than the script file, as the default encodings seemed to cause some problems. I'm still somewhat unsure of what exactly happened, but I am grateful and amazed at Ramnathv, the maintainer of slidify, in actively participating in all these discussions. The story of this fix is also in the links above.

puslet88
  • 1,288
  • 15
  • 25