From ripley at stats.ox.ac.uk  Mon Feb 25 22:06:00 2008
From: ripley at stats.ox.ac.uk (Prof Brian Ripley)
Date: Mon, 25 Feb 2008 21:06:00 +0000 (GMT)
Subject: [Rd] Clipping using par(plt=..., xpd=FALSE) inconsistencies
In-Reply-To: <Pine.LNX.4.64.0802222050040.11702@auk.stats>
References: <07E228A5BE53C24CAD490193A7381BBBEE1114@LP-EXCHVS07.CO.IHC.COM>
	<Pine.LNX.4.64.0802222050040.11702@auk.stats>
Message-ID: <alpine.LFD.1.00.0802252103290.18007@gannet.stats.ox.ac.uk>

The following works in R-devel

      x <- rnorm(1000)
      hist(x, xlim=c(-4,4))
      usr <- par("usr")
      clip(usr[1], -2, usr[3], usr[4])
      hist(x, col = 'red', add = TRUE)
      clip(2, usr[2], usr[3], usr[4])
      hist(x, col = 'blue', add = TRUE)
      do.call("clip", as.list(usr))  # reset to plot region

I think that is a general enough mechanism -- see its help page for how 
long one can expect a clipping region to persist.

On Fri, 22 Feb 2008, Prof Brian Ripley wrote:

> I think you misunderstand what par("plt") is supposed to do.  The 
> documentation says
>
>     'plt' A vector of the form 'c(x1, x2, y1, y2)' giving the
>          coordinates of the plot region as fractions of the current
>          figure region.
>
> You haven't subsequently made a new plot, so why do you expect the clipping 
> region to be changed to that you indicated for the next plot?
>
> I'd say the bug was that box() changed it, and that happens because it 
> internally sets xpd and so resetting xpd sets the clipping region next time 
> it is used.  Because of
>
> void GClip(pGEDevDesc dd)
> {
>    if (gpptr(dd)->xpd != gpptr(dd)->oldxpd) {
> 	double x1, y1, x2, y2;
> 	setClipRect(&x1, &y1, &x2, &y2, DEVICE, dd);
> 	GESetClip(x1, y1, x2, y2, dd);
> 	gpptr(dd)->oldxpd = gpptr(dd)->xpd;
>    }
> }
>
> Maybe we should have user-level code to set the clipping region?
>
>
> On Fri, 22 Feb 2008, Greg Snow wrote:
>
>> Here is a demonstration of behaviour that is probably an optimization by
>> someone far smarter than me that did not anticipate anyone wanting to do
>> this, but for my purposes it looks more like a bug than a feature.
>> 
>> I have tested this with R2.6.2 on Windows, no additional packages loaded
>> (beyond the default), I have tested using the default graphics object,
>> pdf, jpeg, and cairoDevice (ok I loaded a package for that) and all show
>> the same behavior.
>> 
>> Run the following set of commands:
>> 
>> x <- rnorm(1000)
>> hist(x, xlim=c(-4,4))
>> 
>> tmp <- par('plt')
>> 
>> box(col='#00000000')
>> tmp2 <- tmp
>> tmp2[2] <- tmp2[1] + 0.3
>> par(xpd = FALSE, plt=tmp2)
>> hist(x, col='red', add=TRUE)
>> 
>> box(col='#00000000')
>> tmp3 <- tmp
>> tmp3[1] <- tmp3[2] - 0.3
>> par(xpd=FALSE, plt=tmp3)
>> hist(x, col='blue', add=TRUE)
>> par(plt=tmp)
>> 
>> 
>> This gives me the plot that I want and expect (a histogram with the left
>> section red, the middle white/background, and the right blue).
>> 
>> Now comment out or delete the 2 box commands and rerun everything.  The
>> clipping does not happen this time and the final result is a full blue
>> histogram.
>> 
>> Is this a bug? Feature? Something else?
>> Does anyone have a better work around than drawing transparent boxes?
>> 
>> Thanks,
>> 
>> 
>> 
>> 
>
> -- 
> Brian D. Ripley,                  ripley at stats.ox.ac.uk
> Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
> University of Oxford,             Tel:  +44 1865 272861 (self)
> 1 South Parks Road,                     +44 1865 272866 (PA)
> Oxford OX1 3TG, UK                Fax:  +44 1865 272595
>

-- 
Brian D. Ripley,                  ripley at stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595



[Rd] Clipping using par(plt=..., xpd=FALSE) inconsistencies
Prof Brian Ripley