On Thu, 4 Aug 2016 at 11:17 Paul Murrell <p...@stat.auckland.ac.nz> wrote:
> Hi > > Just to clarify, I think this IS a problem with grid.path() as well as > polypath(). > > Hi, oh dear - sorry about that I appreciate the deeper explanation, I knew about the id aspect in grid, but just forgot in my haste. I'll be more careful with examples if I find any more clues. Cheers, Mike. > For the example you give, grid.path() diverts to drawing a polygon > (because there is no 'id' specified), and the NAs in 'x' generate two > separate polygons, which get drawn one on top of the other. > > The correct analogy to the polypath() example is ... > > x2 <- matrix(x[!is.na(x)], ncol=2) > grid.path(x2[,1], x2[,2], id=rep(1:2, each=4), > rule="winding", gp=gpar(="#BEBEBE80")) > > ... which produces the same (wrong) result as polypath() on Windows. > > Also, the grid.path() result for your example is NOT the same as the > correct result; we do NOT want a separate shade for the intersecting > region when the "winding" fill rule is working correctly. The fill > should be the same across the union of the square regions (this is what > Cairo and PDF on Linux produce). > > Another data point: the problem is NOT just a matter of getting the > rules round the wrong way in the devWindows.c; using rule="evenodd" > produces the SAME result as using rule="winding". > > One more data point: this is not JUST a problem with polypath(). > Creating a self-intersecting polygon and then drawing it, using > polygon(), in windows(fillEvenOdd=FALSE) and windows(filleEvenOdd=TRUE) > produces exactly the same result. > > Sadly, none of that helps to explain why the "winding" rule is not > working on Windows :( > > Thanks for reporting the problem - needs more study to find out what is > going wrong. > > Paul > > On 03/08/16 18:47, Michael Sumner wrote: > > Hello, > > > > it's probably worth adding that this is not a problem with pathGrob, only > > polypath. > > > > This code is sufficient to demonstrate the problem in Windows. > > > > ## overlapping, both clock-wise > > x <- cbind(c(.1, .1, .6, .6, NA, .4, .4, .9, .9), > > c(.1, .6, .6, .1, NA, .4, .9, .9, .4)) > > ## only a problem on Windows windows() and png() > > plot(x);polypath(x, rule = "winding", col = "#BEBEBE80") > > > > This code shows the same behaviour on different systems/devices. > > > > ## no problem on Windows/Linux/PNG/PDF ... > > library(grid) > > grid.newpage() > > pushViewport(viewport(0.5, 0.5, width = 1, height = 1)) > > grid.draw(pathGrob(x[,1], x[,2], rule = "winding", gp = gpar(fill = > > "#BEBEBE80"))) > > > > Cheers, Mike. > > > > On Wed, 3 Aug 2016 at 16:24 Michael Sumner <mdsum...@gmail.com> wrote: > > > >> Hi, I see different results in png() and pdf() for polypath() on Windows > >> when using the "winding" rule > >> > >> ## overlapping, both clock-wise > >> x <- cbind(c(.1, .1, .6, .6, NA, .4, .4, .9, .9), > >> c(.1, .6, .6, .1, NA, .4, .9, .9, .4)) > >> > >> pfun <- function() { > >> plot(x) > >> polypath(x * 0.8 + 0.2, rule = "winding", col = "#BEBEBE80") > >> polypath(x, rule = "winding", col = "#BEBEBE80") > >> } > >> > >> ## output "windows.png/pdf" or "unix.png/pdf" > >> label <- .Platform$OS.type > >> png(sprintf("%s.png", label)) > >> pfun() > >> dev.off() > >> pdf(sprintf("%s.pdf", label)) > >> pfun() > >> dev.off() > >> > >> > >> Visually, the result in the "windows.png" file is as if the "evenodd" > rule > >> was specified. All other examples unix.pdf, unix.png, windows.pdf give > me > >> the expected result - which is "all bounded regions shaded grey, with > two > >> tones for the different regions of overlap". The unexpected result is > the > >> completely transparent region. > >> > >> Is this a known/expected difference on Windows? I see the unexpected > >> result in 3.3.1 and in R version 3.3.1 Patched (2016-07-27 r70991) on > >> Windows. > >> > >> Cheers, Mike. > >> -- > >> Dr. Michael Sumner > >> Software and Database Engineer > >> Australian Antarctic Division > >> 203 Channel Highway > >> Kingston Tasmania 7050 Australia > >> > >> -- > > Dr. Michael Sumner > > Software and Database Engineer > > Australian Antarctic Division > > 203 Channel Highway > > Kingston Tasmania 7050 Australia > > > > [[alternative HTML version deleted]] > > > > ______________________________________________ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > -- > Dr Paul Murrell > Department of Statistics > The University of Auckland > Private Bag 92019 > Auckland > New Zealand > 64 9 3737599 x85392 > p...@stat.auckland.ac.nz > http://www.stat.auckland.ac.nz/~paul/ > -- Dr. Michael Sumner Software and Database Engineer Australian Antarctic Division 203 Channel Highway Kingston Tasmania 7050 Australia [[alternative HTML version deleted]] ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel