[Rd] graphics: par(mfg=c(i,j,r,c)) (PR#529)

[Paul Murrell]

hi


> > x_1:20
> > y_1:20
> > #these 5 commands produce a 2x2 panel plot
> > par(mfrow=c(2,2))
> > plot(x,y)
> > plot(x,y)
> > plot(x,y)
> > plot(x,y)
> >
> > #the following 2 commands successfully added the text 'panel[2,1]' to
> > panel[2,1]
> > par(mfg=c(2,1,2,2))
> > text(10,10,'panel[2,1]')
> >
> > #None of the following 3 command-pairs produced their intended results
for the
> > other
> > # 3 panels
> > par(mfg=c(1,2,2,2))
> > text(10,10,'panel[1,2]')
> >
> > par(mfg=c(1,1,2,2))
> > text(10,10,'panel[1,1]')
> >
> > par(mfg=c(2,2,2,2))
> > text(10,10,'panel[2,2]')
> >
> > #However, the following command-pair did as intended on the first panel
> > specified
> > # by mfg=c(2,1,2,2) above
> > par(mfg=c(2,1,2,2))
> > text(15,15,'panel[2,2]')
>
> Same thing happens on Linux. Might be something with restoring the
> coordinate transformations. Using
>
> par(mfg=c(1,1,2,2))
> plot(x,y)
> text(10,10,'panel[1,1]')
>
> *does* seem to work.


This was a clipping bug, to do with the fact that GClip only reset the
device's clipping region if the value of dd->gp.xpd changed.

I have committed a fix, which *forces* a reset of the clipping region when
par(xpd) is set.

For the record:  this just fixes the par(xpd) situation.  The problem may
resurface elsewhere, in which case it may be worth considering changing
GClip to *always* force a reset of the clipping region.

paul


-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._