Closed trevorld closed 2 years ago
Apparently this is a pdf viewer bug in evince
(my default pdf viewer) and not a bug in the pdf file. The pdf
looks fine in other pdf viewers such as firefox
and okular
and reportedly xpdf
and chrome
.
More minimal example of pdf output to explore pdf viewer bug with alpha masks:
library("grid")
x <- c(0.1, 0.9, 0.9, 0.1, 0.1, 0.3, 0.7, 0.7, 0.3, 0.3)
y <- c(0.1, 0.1, 0.9, 0.9, 0.1, 0.3, 0.3, 0.7, 0.7, 0.3)
id.lengths <- c(5L, 5L)
rule <- "evenodd"
gp <- gpar(fill = "black", lwd = 0L)
masker <- pathGrob(x, y, id.lengths = id.lengths, rule = "evenodd", gp = gp)
masked <- rectGrob(height = unit(0.7, "npc"),
gp = gpar(fill = "yellow", lwd = 4, col = "blue"),
vp = viewport(mask = masker))
grDevices::pdf("mask_bug.pdf")
grid.draw(masked)
dev.off()
Looking at the output of pdftocairo -png -f 1 -l 1 mask_bug.pdf -o cairo-output
and pdftoppm -png -f 1 -l 1 mask_bug.pdf -o splash-output
it appears that the bug is in poppler
's "cairo" backend and not poppler
's "splash" backend. This is why the pdf looks fine in okular
(uses poppler
's "splash" backend) but not evince
(uses poppler
's "cairo" backend) even though both use poppler
as their pdf backend.
Bug reported upstream to poppler
: https://gitlab.freedesktop.org/poppler/poppler/-/issues/1202
Is this problem solved?
Is this problem solved?
poppler
developers fixed the bug upstream? Haven't seen any evidence that they have done so. It may actually be a bug in Cairo but either way the evince
snap provided by Ubuntu still has the bug. If I compile poppler
manually with the Cairo headers available by apt
in Ubuntu 20.04 LTS I still get the bug.poppler
and won't be implementing a hack on their end in grDevices::pdf()
to work around itYou can avoid this problem by:
1) Turn off the alpha mask optimization: options(ggpattern_use_R4.1_masks = FALSE)
(this will slow down rendering)
2) Use a different graphics device like ragg::agg_png()
or perhaps grDevices::cairo_pdf()
(but note with the latter if you haven't upgraded to R 4.2 then you may hit a limit in Cairo devices on number of masks #59)
3) Use a different pdf viewer like okular
, firefox
, google-chrome
, etc.
@trevorld Thanks for your detailed explanation.
1.1 options(ggpattern_use_R4.1_masks = F)
and grDevices::cairo_pdf
:
In this situation, pattern is not in vector form, and looks blurry.
1.2 options(ggpattern_use_R4.1_masks = T)
and grDevices::cairo_pdf
:
Mask is error.
2.1 options(ggpattern_use_R4.1_masks = F)
and Cairo::CairoPDF
:
2.2 options(ggpattern_use_R4.1_masks = T)
and Cairo::CairoPDF
:
Same error as 2.1
I need a line pattern. Any idea how to make it?
1.1, 2.1, 2.2 - Yes, the non-alpha mask alternative is a rasterGrob()
approximation. However you can increase the resolution via the pattern_res
aesthetic or alternatively by setting the ggpattern_res
option via options()
.
1.2 - The cairo_pdf()
alpha mask error should theoretically go away if you upgrade to R 4.2
Thanks for your solution. R 4.2 is not available on the official website. Do you know how to upgrade to 4.2? I am using ubuntu and win10.
./configure; make; sudo make install
Also {svglite}
recently added support for the R 4.1 alpha masking feature. If you really need a vectorized image format could try saving an "svg" file with svglite::svglite()
and then converting to pdf...
Workarounds
Use ragg::agg_png() or perhaps rasterpdf::agg_pdf() instead
Set options(ggpattern_use_R4.1_masks = FALSE) to use the raster masking alternative to the R 4.1 masking feature