Special characters read from .xlsx or .csv files not rendered correctly

[CarlosPoses]

I am trying to create an entry with some projects' information based on an Excel file in which I have stored information about these projects. Some projects have a Spanish name and thus use some special characters (like : á). When I knit the document, these are rendered incorrectly.

But the behavior is not the same if instead of reading the files from an excel file I create a tibble in the code itself, using the exact same names.

See code below, and excel file attached.
repex.xlsx

---
name: Marie
surname: Curie
position: "Professor"
address: "School of Physics & Chemistry, École Normale Supérieure"
phone: +1 22 3333 4444
www: mariecurie.com
email: "[email protected]"
twitter: mariecurie
github: mariecurie
linkedin: mariecurie
date: "`r format(Sys.time(), '%B %Y')`"
output: vitae::moderncv
---

```{r setup, include=FALSE}
knitr::opts_chunk$set(echo = FALSE, warning = FALSE, message = FALSE)
library(vitae)
library(readxl)
library(tidyverse)
```

# Projects

```{r}

projects_tibble <- tibble(
  title = "Política y Economía",
  role = "Researcher",
  year = 2012
)

projects_tibble %>% 
  detailed_entries(
    what = title,
    with = role,
    when = year)

projects_excel <- readxl::read_excel("repex.xlsx")

projects_excel %>% 
  detailed_entries(
    what = title,
    with = role,
    when = year)

```

When knitted, projects_tibble works as expected, but projects_excel does not. Seems related to #158 and #167 , but this is not for .bib files but for .xlsx files. I would say the issue is not fixed for these kind of files? I tried but got the same problem using .csv files instead of an .xlsx file. Also converting the projects_excel to a tibble once read did not seem to work either.

[mitchelloharawild]

I'm unable to reproduce this issue.

Are you using Windows? It is likely an encoding related problem upstream in the readxl package. Could you try installing the dev version of readxl, and see if projects_tibble and projects_excel differ in a meaningful way? You can use waldo::compare(projects_tibble, projects_excel) to compare the results.

[CarlosPoses]

Hi,

Thanks a lot for your help! I am using Windows indeed. I have done as suggested as this is what I get:

It seems the issue is in the backslash - but not sure what to make about it. I tried reading the excel file with openxlsx instead. It did not solve the issue. I get this:

Seems the issue is the backslash again. Do you know if there's something that can be done about this?

Best,

Carlos

[CarlosPoses]

Hi,

If anybody out there is struggling with the same issue: apart from writing a tibble with all entries (which can be very tiring, especially for long entries), a workaround is to write only the entries with special characters in a tibble. For instance:

special_entry <-tibble(position = "Tu posición", role = "Your role", year = "Any year")

And then

bind_rows(special_entry, rest_of_the_spreadsheet)

Where rest_of_the_spreadsheet is an object based on a normal .csv or .xlsx file where you have the data you wanted to use originally. You should delete the entry(s) with special characters from that spreadsheet. This is not an optimal solution but it can save time if you only have a few entries with special characters.

Anyway, any chance this might be more generally solved? This is a big drawback for using vitae with .xlsx or .csv in many languages other than English and in Windows - which I guess it is not a very uncommon setting. Most sentences in Spanish have special characters so my sketch above is not very practical if you have a full CV in Spanish.

Again, best and thanks for developing the package which is very nice!

[mitchelloharawild]

Thanks for the proposed alternative solution. I'm able to reproduce your issue on one of my Windows systems. I believe this is an issue with encoding in your excel file, or how the readxl package is reading it. You may find better help raising an issue with the readxl maintainers.

[mitchelloharawild]

Closing as this is not an issue that can/should be fixed in {vitae}. The problem relates to the method used to import the data (using {readxl}) and not how {vitae} handles the provided data.