Greg Snow
2008-Feb-22  19:09 UTC
[Rd] Clipping using par(plt=..., xpd=FALSE) inconsistencies
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,
-- 
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
greg.snow at imail.org
(801) 408-8111
Prof Brian Ripley
2008-Feb-22  21:06 UTC
[Rd] Clipping using par(plt=..., xpd=FALSE) inconsistencies
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
Maybe Matching Threads
- pairs, par("plt")
 - adding custom axis to image.plot() and strange clipping behavior
 - Different results based on the order of arguments to par
 - abline() AND rect() do not obey "xpd" (clipping) (PR#750)
 - [FORGED] Different results based on the order of arguments to par