[Rd] [FORGED] Re: polypath winding rule with transparency

[Michael Sumner]

On Thu, 4 Aug 2016 at 11:17 Paul Murrell <paul at 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 <mdsumner at 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 at 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
> paul at 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]]