9

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.

Corner of map with wrong degree sign

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) additional example of wrong degree sign

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: test

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

test from pdf

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

giocomai
  • 3,043
  • 21
  • 24
  • 4
    Can you test if this is actually a ggplot/sf problem. More likely stems from plotmath or elsewhere in R. What do you get if you run `plot.new(); text(0.5,0.5, bquote(120*degree*N), cex=5)`? – dww Mar 15 '20 at 20:34
  • 1
    you're right, I get the same issue... will update question in a second – giocomai Mar 15 '20 at 20:43
  • 2
    What symbol prints when you call the unicode character directly? E.g. plot.new(); text(0.5,0.5, bquote(paste("120", "\u00B0", "N", sep = "")), cex=5) – jared_mamrot Mar 18 '20 at 05:11
  • 1
    @jpmam1 the correct ° sign, exactly as expected – giocomai Mar 18 '20 at 08:44
  • 1
    is this a plotting issue, or does it happen in exports? I had a similar issue on Ubuntu when saving files with accented characters; I was able to overcome it by executing `pdf.options(encoding = 'ISOLatin2')` – Jindra Lacko Mar 19 '20 at 17:00
  • This happens when I plot in the view pane, and when I save e.g. with cairo_pdf(), but does not happen e.g. when I use knitr in an Rmd file. All looks good if I knit. – giocomai Mar 19 '20 at 17:05

3 Answers3

9

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
jared_mamrot
  • 22,354
  • 4
  • 21
  • 46
  • this is a workaround, not a solution, of course using custom scales this can be fixed, as mentioned in the SO answer linked in the question. It also does not keep the N/S and E/W notation that is a necessary part of coordinates. Of course, with further cusomisation and if statements, this could be approached, but it is not a solution. – giocomai Mar 19 '20 at 11:14
  • thanks a lot for the update, looks great. I'll bring to the attention of upstream. If no better option, bounty goes here – giocomai Mar 20 '20 at 08:07
  • unfortunately, this is not a workable solution, as downgrading pango breaks 'nautilus' - "nautilus: symbol lookup error: nautilus: undefined symbol: pango_attr_insert_hyphens_new! – giocomai Mar 20 '20 at 09:00
3

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).

enter image description here

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.

dww
  • 30,425
  • 5
  • 68
  • 111
  • this looks very helpful, thanks. quick reply... even with locale set to en_US.UTF-8, or C, I basically can see none of these signs (i.e. I see 00B0 for all of them), with the exception of the very last one, and the dot (second from bottom on column 6). Cairo is the type in X11.options(), and I see the same changing the device. Will check `?plotmath` first and then add details to the question. thanks again! – giocomai Mar 19 '20 at 16:51
  • added details to question – giocomai Mar 19 '20 at 17:21
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.

giocomai
  • 3,043
  • 21
  • 24