How to fix degree symbol not showing correctly in R on Linux/Fedora 31

Question

Any map I make with:

ggplot() + geom_sf()

produces the expected map, but does not show the degree sign correctly, as appears from the following picture.

The answer given in this answer on SO - degree symbol incorrect in map axis labels - does not help, and I am posting a separate question as I see a different sign.

Changing font does not help.

I've also tried installing the current version of sf (0.9) from Github in a separate project with renv, but have the same result.

I'm on Linux, Fedora 31.

To replicate:

library("ggplot2")
library("sf")
nc <- st_read(system.file("shape/nc.shp", package="sf"))

ggplot() +
  geom_sf(data = nc)

2019-03-15 update

The issue is not specific to ggplot/geom_sf; as suggested in the comments, I get the same issue with plot.new(); text(0.5,0.5, bquote(120*degree*N), cex=5)

Also, to clarify, I have not the issue related to Wine detailed in the help of ?X11(). If I run in my terminal, fc-match Symbol, I get:

StandardSymbolsPS.t1: "Standard Symbols PS" "Regular"

Update 2019-03-19

Confirmed on a fresh Fedora 31 and Fedora 32 beta install. Probably a Fedora issue.

I tried with different locales (including e.g. "en_US.UTF-8" or "German") and devices (e.g. cairo_pdf(), cairo_ps()) with the same result.

X11.options() shows "cairo" as type (changing it to Xlib, or dbcairo does not change the result).

Using the TestChars() function proposed by dww in the answer below shows the following:

However, if I knit to pdf with knitr, I get most symbols, including °.

If I knit to html, I get the usual garbled signs.

2020-03-20 update

As suggested by @jpmam1, this seems to be related to a regression in pango, that can be temporarily fixed by downgrading pango. Dowgrading pango however, breaks other core parts of the OS, such as nautilus.

I opened a bug on Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=1815128

Answer 1

Here are two solutions for your problem using R (ver3.6.3 2020-02-29) / R Studio (ver1.2.5033) running on a Fedora 31 VirtualBox VM:

1) Insert the unicode character using custom scales to produce the correct symbols (include N/S or E/W depending on your long/lat):

#install.packages("ggplot2")
#install.packages("sf")
library("ggplot2")
library("sf")

nc <- st_read(system.file("shape/nc.shp", package="sf"))

ggplot() +
  geom_sf(data = nc) +
  scale_x_continuous(labels = function(x) paste0(x, '\u00B0', "W")) +
  scale_y_continuous(labels = function(x) paste0(x, '\u00B0', "N"))

2) Downgrade the pango library. In Fedora 31, pango was upgraded to 1.44, which affects bitmap fonts like the default R-Studio font due to the switch from Freetype to HarfBuzz. Downgrading the package fixes rendering of special characters system-wide. This should solve the problem in Fedora 32 as well (untested).

sudo dnf downgrade --releasever 30 pango-1.43.0-4.fc30.x86_64

Answer 2

This is not so much an answer as some diagnostics to try, which are too long to put in a comment.

Note that the "strange symbol" you see is what you get when a symbol is not available in the specified font.

Before we get stuck into diagnostics, also note that from ?plotmath:

On Unix-alikes: In a UTF-8 locale any Unicode character can be entered, perhaps as a \uxxxx or \Uxxxxxxxx escape sequence, but the issue is whether the graphics device is able to display the character. The widest range of characters is likely to be available in the X11 device using cairo: see its help page for how installing additional fonts can help. This can often be used to display Greek letters in bold or italic.

In non-UTF-8 locales there is normally no support for symbols not in the languages for which the current encoding was intended.

Now some things to try to investigate the cause:

1. To get info about your locale

Sys.getlocale()

2. To see your default x11 settings:

X11.options()

We are especially interested in the type to see if the x11 device is using cairo. If it is not, try setting the cairo option in X11.options() to see if that helps

3. To see which characters are available enter the following:

TestChars <- function(...)
{
  info = l10n_info()
  r <- c(32:126, 160:254)
  par(pty = "s")
  plot(c(-1,10), c(20,260), type = "n", xlab = "", ylab = "", xaxs = "i", yaxs = "i")
  grid(11, 24, lty = 1)
  mtext(paste("MBCS:", info$MBCS, "  UTF8:", info$`UTF-8`, "  Latin:", info$`Latin-1`))
  for(i in r) try(points(i%%10, 10*i%/%10, pch = i, font = 5,...))
  points(6,170, col='red', cex=5)
}
TestChars()

On my system it looks like this (note I drew a circle to highlight symbol 176, the one you are having issues with).

4. to see which symbols are available on other graphics devices

Try using the TestChars function on different devices, to see if any of them have a complete set. For example,

cairo_pdf()
TestChars()
dev.off()

If after trying these things you are still stuck, enter the diagnostic results back into your question in case they can help others to resolve the issue.

Answer 3

As it turns out, this misbehaviour is caused by legacy use of symbols in R itself.

This will likely be fixed upstream in R itself: https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17748 which references the downstream issue I opened for Fedora after the feedback I received to this question: https://bugzilla.redhat.com/show_bug.cgi?id=1815128

A functioning workaround has been published by Iñaki Ucar on the R mailing list: https://stat.ethz.ch/pipermail/r-devel/2020-March/079185.html

I copy it here for reference:

$ sudo dnf install gdouros-symbola-fonts

Then add the following to /etc/fonts/local.conf (system-wide) or ~/.fonts.conf (just for your user):

<fontconfig>
<match target="pattern">
 <test name="family"><string>Symbol</string></test>
 <edit name="family" mode="prepend" binding="same">
   <string>Symbola</string>
 </edit>
</match>
</fontconfig>

Now you should see this:

$ fc-match Symbol
Symbola.ttf: "Symbola" "Regular"

and symbols should render correctly.

Again, credit for this solution goes to Iñaki Ucar.

Thank you all who provided answers to this question for assistance in troubleshooting and facilitating this process. Hopefully, this will be fixed upstream in R core itself.