some characters are not rendered correctly on Windows

[yutannihilation]

Also, if I increase the size of such characters (e.g. cex = 100), the R session crashes.

diamond <- "\u25C6"
diamond
#> [1] "◆"

do_plot <- function(dev) {
  file <- tempfile(fileext = ".png")
  dev(file)
  plot.new()
  text(0.5, 0.5, col = "red", cex = 30, label = diamond)
  dev.off()
  
  knitr::include_graphics(file)
}

do_plot(png)

do_plot(ragg::agg_png)

^{Created on 2022-02-23 by the reprex package (v2.0.1)}

[thomasp85]

Is this still an issue? I remember fixing an issue like this related to emoji rendering at large sizes

[yutannihilation]

Yes, I still see this issue. Note that, the above reprex was on R 4.1 (if I remember correctly), and this one is on R 4.2.

packageVersion("ragg")
#> [1] '1.2.2.9000'
packageDescription("ragg")$GithubSHA1
#> [1] "e88bebd28c31108373fda1465ae3b87b265858dc"

diamond <- "\u25C6"
diamond
#> [1] "◆"

do_plot <- function(dev) {
  file <- tempfile(fileext = ".png")
  dev(file)
  plot.new()
  text(0.5, 0.5, col = "red", cex = 30, label = diamond)
  dev.off()
  
  knitr::include_graphics(file)
}

do_plot(png)

do_plot(ragg::agg_png)

^{Created on 2022-08-01 by the reprex package (v2.0.1)}

[thomasp85]

Can I get you to give me the result of systemfonts::font_fallback(diamond)?

[yutannihilation]

Here it is. It seems seguiemj.ttf is a font for emojis, but ◆ is not an emoji?

diamond <- "\u25C6"
systemfonts::font_fallback(diamond)
#>                               path index
#> 1 C:\\WINDOWS\\Fonts\\seguiemj.ttf     0

^{Created on 2022-08-02 by the reprex package (v2.0.1)}

[thomasp85]

Whether or not it is an actual emoji doesn't really matter. The glyph is in the emoji font. Anyway, this is good info since it indicates we are still dealing with the same underlying issue as before

[thomasp85]

Sorry to keep debugging through you but I don't currently have a windows machine at hand. If you do this:

text(0.5, -0.3, col = "red", cex = 30, label = diamond, family = 'Segoe UI Emoji')

does the issue still persist?

[yutannihilation]

No problem at all. Yes, I still see the issue. What's curious is the warning "font family not found in Windows font database" on base png(); it seems you are right in that 'Segoe UI Emoji' contains the glyph, but for some reason it's not available on Windows R session... Does this matter on ragg?

diamond <- "\u25C6"

do_plot <- function(dev) {
  file <- tempfile(fileext = ".png")
  dev(file)
  plot.new()
  text(0.5, -0.3, col = "red", cex = 30, label = diamond, family = 'Segoe UI Emoji')
  dev.off()
  
  knitr::include_graphics(file)
}

do_plot(png)
#> Warning in text.default(0.5, -0.3, col = "red", cex = 30, label = diamond, :
#> font family not found in Windows font database

do_plot(ragg::agg_png)

# no seguiemj.ttf here
systemfonts::system_fonts() |>
  dplyr::select(path, name, family) |> 
  dplyr::filter(grepl("segoe", path))
#> # A tibble: 10 × 3
#>    path                                name               family      
#>    <chr>                               <chr>              <chr>       
#>  1 "C:\\WINDOWS\\Fonts\\segoepr.ttf"   SegoePrint         Segoe Print 
#>  2 "C:\\WINDOWS\\Fonts\\segoeprb.ttf"  SegoePrint-Bold    Segoe Print 
#>  3 "C:\\WINDOWS\\Fonts\\segoesc.ttf"   SegoeScript        Segoe Script
#>  4 "C:\\WINDOWS\\Fonts\\segoescb.ttf"  SegoeScript-Bold   Segoe Script
#>  5 "C:\\WINDOWS\\Fonts\\segoeui.ttf"   SegoeUI            Segoe UI    
#>  6 "C:\\WINDOWS\\Fonts\\segoeuib.ttf"  SegoeUI-Bold       Segoe UI    
#>  7 "C:\\WINDOWS\\Fonts\\segoeuiz.ttf"  SegoeUI-BoldItalic Segoe UI    
#>  8 "C:\\WINDOWS\\Fonts\\segoeuii.ttf"  SegoeUI-Italic     Segoe UI    
#>  9 "C:\\WINDOWS\\Fonts\\segoeuil.ttf"  SegoeUI-Light      Segoe UI    
#> 10 "C:\\WINDOWS\\Fonts\\segoeuisl.ttf" SegoeUI-Semilight  Segoe UI

^{Created on 2022-08-03 by the reprex package (v2.0.1)}

[thomasp85]

The fact that png() doesn't know about it is nothing new - it has very little knowledge of any fonts whatsoever...

Interestingly I can't reproduce this using Segoe UI on my Mac 🤔

I'll dig deeper

[thomasp85]

Beginning to dig into this. I think the main issue is that on Windows, single colour glyphs from a color font are rendered in monochrome, while ragg expects them to be in full colour... I need to figure out how to best inspect and catch this behaviour

[DanChaltiel]

Hi,
I might be experiencing a revival of this issue.
The following code yields a blank plot in the RStudio plot panel:

plot.new()
black_diamonds <- "\u25C6"
text(0.5, 0.5, col = "red", cex = 30, labels = black_diamonds)

However, it works fine in reprex() and in a base R console, although I'm not able to identify the cause.
Do you think I should open a new issue? Here or in RStudio's GitHub?

Session info

sessioninfo::session_info()
#> - Session info ---------------------------------------------------------------
#>  setting  value
#>  version  R version 4.1.3 (2022-03-10)
#>  os       Windows 10 x64 (build 19045)
#>  system   x86_64, mingw32
#>  ui       RTerm
#>  language en
#>  collate  French_France.1252
#>  ctype    French_France.1252
#>  tz       Europe/Paris
#>  date     2024-04-10
#>  pandoc   3.1.1 @ C:/Users/d_chaltiel/AppData/Local/Programs/RStudio/resources/app/bin/quarto/bin/tools/ (via rmarkdown)
#> 
#> - Packages -------------------------------------------------------------------
#>  package     * version date (UTC) lib source
#>  cli           3.6.1   2023-03-23 [1] CRAN (R 4.1.3)
#>  curl          5.0.0   2023-01-12 [1] CRAN (R 4.1.3)
#>  digest        0.6.34  2024-01-11 [1] CRAN (R 4.1.3)
#>  evaluate      0.21    2023-05-05 [1] CRAN (R 4.1.3)
#>  fastmap       1.1.1   2023-02-24 [1] CRAN (R 4.1.3)
#>  fs            1.5.2   2021-12-08 [1] CRAN (R 4.1.3)
#>  glue          1.6.2   2022-02-24 [1] CRAN (R 4.1.3)
#>  highr         0.10    2022-12-22 [1] CRAN (R 4.1.3)
#>  htmltools     0.5.5   2023-03-23 [1] CRAN (R 4.1.3)
#>  knitr         1.43    2023-05-25 [1] CRAN (R 4.1.3)
#>  lifecycle     1.0.4   2023-11-07 [1] CRAN (R 4.1.3)
#>  magrittr      2.0.3   2022-03-30 [1] CRAN (R 4.1.3)
#>  purrr         1.0.1   2023-01-10 [1] CRAN (R 4.1.3)
#>  R.cache       0.16.0  2022-07-21 [1] CRAN (R 4.1.3)
#>  R.methodsS3   1.8.2   2022-06-13 [1] CRAN (R 4.1.3)
#>  R.oo          1.25.0  2022-06-12 [1] CRAN (R 4.1.3)
#>  R.utils       2.12.2  2022-11-11 [1] CRAN (R 4.1.3)
#>  reprex        2.0.2   2022-08-17 [1] CRAN (R 4.1.3)
#>  rlang         1.1.3   2024-01-10 [1] CRAN (R 4.1.3)
#>  rmarkdown     2.25    2023-09-18 [1] CRAN (R 4.1.3)
#>  rstudioapi    0.14    2022-08-22 [1] CRAN (R 4.1.3)
#>  sessioninfo   1.2.2   2021-12-06 [1] CRAN (R 4.1.3)
#>  styler        1.10.1  2023-06-05 [1] CRAN (R 4.1.3)
#>  vctrs         0.6.1   2023-03-22 [1] CRAN (R 4.1.3)
#>  withr         3.0.0   2024-01-16 [1] CRAN (R 4.1.3)
#>  xfun          0.39    2023-04-20 [1] CRAN (R 4.1.3)
#>  xml2          1.3.3   2021-11-30 [1] CRAN (R 4.1.3)
#>  yaml          2.3.7   2023-01-23 [1] CRAN (R 4.1.3)
#> 
#>  [1] C:/Users/d_chaltiel/Documents/R/R-4.1.3/library
#> 
#> ------------------------------------------------------------------------------

[thomasp85]

I find it unlikely that it is the same root cause. Can you see if you can reproduce the issue using ragg::agg_png() instead of the plotting pane. Then we'll know for sure if ragg is to blame

[DanChaltiel]

@thomasp85 Thanks for your response
You guessed right, ragg::agg_png() worked as intended.
Where should I report this bug then? RStudio's GitHub has so many issues I don't want to bloat it if the problem comes from somewhere else...