pdf() device transparency problems with shape = "outline"

[hughjonesd]

I just tested the "Texas" commands and I see that it works for PDF but not PNG Device.

However, while the transparency of the backbround of the PDF version is achieved, the Texas state itself is not colored red. With shadow = TRUE there is a gray coloring inside. With shadow = FALSE there is only the orange outline. I colored the rest of the states "green4" with "yellow" lines to make the image different. Here are the PDF (Device) output using pdf(file="Texasplot2.pdf") and dev.off():

(Saving to PNG looks the same as the one on the first comment, with a red Texas but blue neighbours.)

Originally posted by @jsgro in https://github.com/hughjonesd/ggmagnify/issues/22#issuecomment-1920038263

[hughjonesd]

Bug checks out on my machine too. Using bg = "white" in the pdf call doesn't fix it.

[hughjonesd]

shape = "rect" and "ellipse" both work OK with PDF, so it must be specific to the "outline".

[hughjonesd]

The problem is not border_grob replacing the colour with transparency. Seems to be to do with the mask grob; setting mask_grob = FALSE works fine but then obviously leaves a square inset.

[hughjonesd]

A workaround on Mac is to use the cairo_pdf() device, which works nicely. That may also work on other platforms where it is supported.

My guess is that the original pdf() device lacks some of the compositing options mentioned in dev.capabilities().

[hughjonesd]

Added documentation on recommended graphics devices in the help file. Leaving this open for others to find.

[jsgro]

Thanks for keeping this open... Glad you added the paragraph Graphics devices under Tips and tricks. I followed the information and here are suggestions to clarify the text:

• the package is called ragg (install.packages('ragg') as trying to install ragg_png causes error.)
• the command is not ragg_png but agg_png as I found in the ragg package README.html

I think that having this information at the Top of the README file would be useful as other people might not realize agg_png was the device used. While this creates the best image, most users would not know about it...

I see that there are other options within that package for other formats and has great features (speed, font access etc.) Well worth the discovery! Thanks. JYS

[hughjonesd]

Yes, but from knitr the device option must be set to "ragg_png" (and no, I don't know why this name was chosen...) See README.Rmd source for an example.

[jsgro]

I love knitr, bookdown and all of these packages! However, when teaching or discovering a new package (such as yours this week) in e.g. a class setting it is usually easier to either type on the console or work from an R script file. In that case we would not use knitr methods until those students learn a bit more about markdown and Rmarkdown and the related concepts. Therefore the "standard" way to use this ragg package would be to create a plot object, and then use the more standard approach to open/close the file. For example:

library(ragg)
agg_png(file="Texasplot_ragg.png")
ggpm_w_inset # ggplot object with inset
dev.off()

> I don't know why this name was chosen...

I found that ragg_png is defined as a function within the plot.R file within the knitr package as such on lines 113-116:

    # similar to load_device(), but the `dpi` argument is named `res`
    ragg_png = function(...) {
      ragg::agg_png(..., res = dpi, units = 'in')
    },

I still believe that the "standard" method should be clearly mentioned, perhaps with the link to the ragg package README.html for those using knitr. Best - JYS

[hughjonesd]

You can't hold people's hands too much. Otherwise, you just end up reproducing other packages' documentation. Then you have increased the burden on yourself, and when the other package updates, your docs are inaccurate. It's fine to expect people to figure out agg_png/ragg_png by themselves.

[hughjonesd]

Also again, no offence, but this is an issue tracker, not a forum. I didn't notice till now, but this question is completely irrelevant to this issue. That makes it harder for me to track the state of play for the actual bug. Please keep issues separate.