polypath winding rule with transparency

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

polypath winding rule with transparency

Michael Sumner-2
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

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: polypath winding rule with transparency

Michael Sumner-2
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 <[hidden email]> 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]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

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

Paul Murrell-2
Hi

Just to clarify, I think this IS a problem with grid.path() as well as
polypath().

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 <[hidden email]> 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]]
>
> ______________________________________________
> [hidden email] 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
[hidden email]
http://www.stat.auckland.ac.nz/~paul/

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

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

Michael Sumner-2
On Thu, 4 Aug 2016 at 11:17 Paul Murrell <[hidden email]> 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 <[hidden email]> 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]]
> >
> > ______________________________________________
> > [hidden email] 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
> [hidden email]
> 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]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: polypath winding rule with transparency

Michael Sumner-2
On Thu, 4 Aug 2016 at 17:53 Michael Sumner <[hidden email]> wrote:

> On Thu, 4 Aug 2016 at 11:17 Paul Murrell <[hidden email]> 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.
>
>
I've found a possibly related issue, again only on Windows as far as I can
see.

These two plots give different results, the second is completely
transparent rather than the expected light blue region on the left.
Whether it works or not seems to depend on the specific geometry of the
device and *not on the specific xlim interval chosen*. I can get the
problem to come and by interactively resizing the window resulting from the
first plot. Somehow it's related to the intersection-detection of the
filled polygon with the plot region (?).

pp <- matrix(c(0, 0,
               0, 1,
               1, 1,
               1, 0,
               0, 0), ncol = 2, byrow = TRUE)

xlim <- c(0.24, 1.5)  ## ok at xlim[1] = 0.24
## first plot, ok (but also try resizing the window by dragging the left
side out)
plot(pp, main = "winding/transparent", xlim = xlim)
polypath(pp, col = "#ADD8E6E6", rule = "winding")


xlim <- c(0.25, 1.5)
## second plot, not ok
plot(pp, main = "winding/transparent", xlim = xlim)
polypath(pp, col = "#ADD8E6E6", rule = "winding")


Cheers, Mike.



> 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 <[hidden email]> 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]]
>> >
>> > ______________________________________________
>> > [hidden email] 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
>> [hidden email]
>> http://www.stat.auckland.ac.nz/~paul/
>>
> --
> 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]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: polypath winding rule with transparency

Paul Murrell-2

Thanks for the additional information.  I see the behaviour that you are
reporting (on Windows), which is pretty weird behaviour!
Hopefully this will shed some light on the other problem that you
reported, rather than being another unrelated problem.

Paul

On 24/04/2017 1:37 p.m., Michael Sumner wrote:

>
>
> On Thu, 4 Aug 2016 at 17:53 Michael Sumner <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     On Thu, 4 Aug 2016 at 11:17 Paul Murrell <[hidden email]
>     <mailto:[hidden email]>> 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.
>
>
> I've found a possibly related issue, again only on Windows as far as I
> can see.
>
> These two plots give different results, the second is completely
> transparent rather than the expected light blue region on the left.
> Whether it works or not seems to depend on the specific geometry of the
> device and *not on the specific xlim interval chosen*. I can get the
> problem to come and by interactively resizing the window resulting from
> the first plot. Somehow it's related to the intersection-detection of
> the filled polygon with the plot region (?).
>
> pp <- matrix(c(0, 0,
>                0, 1,
>                1, 1,
>                1, 0,
>                0, 0), ncol = 2, byrow = TRUE)
>
> xlim <- c(0.24, 1.5)  ## ok at xlim[1] = 0.24
> ## first plot, ok (but also try resizing the window by dragging the left
> side out)
> plot(pp, main = "winding/transparent", xlim = xlim)
> polypath(pp, col = "#ADD8E6E6", rule = "winding")
>
>
> xlim <- c(0.25, 1.5)
> ## second plot, not ok
> plot(pp, main = "winding/transparent", xlim = xlim)
> polypath(pp, col = "#ADD8E6E6", rule = "winding")
>
>
> Cheers, Mike.
>
>
>
>     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 <http://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 <[hidden email]
>         <mailto:[hidden email]>> 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]]
>         >
>         > ______________________________________________
>         > [hidden email] <mailto:[hidden email]> 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
>         [hidden email] <mailto:[hidden email]>
>         http://www.stat.auckland.ac.nz/~paul/
>
>     --
>     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
>

--
Dr Paul Murrell
Department of Statistics
The University of Auckland
Private Bag 92019
Auckland
New Zealand
64 9 3737599 x85392
[hidden email]
http://www.stat.auckland.ac.nz/~paul/

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel