Hi all -- I just encountered a behavior that I believe has changed
from previous versions, though I haven't chased back the last version
that behaves as my existing code expects quite yet.
Perhaps this is a bug, though perhaps I'm missing a subtle detail
somewhere in the documentation...
Here's some code that works as expected (in R 3.1.1):
########################################
pdf()
plot.new()
original_plt <- par("plt")
plt_1 <- c(original_plt[1],
original_plt[1] + (original_plt[2] - original_plt[1]) / 2,
original_plt[3],
original_plt[3] + (original_plt[4] - original_plt[3]) / 2)
par("plt" = plt_1)
plot.window(xlim = c(0, 1), ylim = c(0, 1))
box()
plt_2 <- c(plt_1[2],
original_plt[2],
plt_1[4],
original_plt[4])
par("plt" = plt_2)
plot.window(xlim = c(0, 1), ylim = c(0, 1))
box()
par("plt" = original_plt)
box(lty = 2)
dev.off()
########################################
This will draw 3 boxes... one in the lower left corner (specified by
plt_1), one in the top right corner (specified by plt_2), and one
dotted box around the full plot box (original_plt).
Now, if you replace the first two box() calls by: rect(0, 0, 1, 1),
only the lower-left rectangle is drawn.
If you _add_ rect(0, 0, 1, 1) after each box() call, all boxes and
rectangles are correctly drawn.
It seems that after setting plt once, subsequent plt alterations put
the device into a state that will permits drawing of _some_ things
(e.g. box()), but not other things (e.g. rect, lines, points).
A kludge to fix this is to call box(col = "white")... but that's
quite
the kludge, indeed!
Axis() works just like box(), too... but I haven't exhausted which
drawing functions work and which don't.
I'd classify this is a bug, but I thought I'd check here first.
I've also only checked this so far with the pdf() device, so I don't
know if it is somehow device-specific.
I detected this because some existing code (that worked on some
earlier version of R, sorry that I don't know which one yet...) has
suddenly stopped working!
Cheers!
-murat
Another (easier) kludge is augmenting a call to each par("plt" = ...)
call:
par("plt" = some_plt_coordinates); box(lty = 0)
The box(lty = 0) addition makes downstream calls work as expected, but
yeah... this is a kuldge.
-m
On Mon, Oct 6, 2014 at 12:00 PM, Murat Tasan <mmuurr at gmail.com>
wrote:> Hi all -- I just encountered a behavior that I believe has changed
> from previous versions, though I haven't chased back the last version
> that behaves as my existing code expects quite yet.
> Perhaps this is a bug, though perhaps I'm missing a subtle detail
> somewhere in the documentation...
>
> Here's some code that works as expected (in R 3.1.1):
>
> ########################################
> pdf()
> plot.new()
>
> original_plt <- par("plt")
>
> plt_1 <- c(original_plt[1],
> original_plt[1] + (original_plt[2] - original_plt[1]) / 2,
> original_plt[3],
> original_plt[3] + (original_plt[4] - original_plt[3]) / 2)
> par("plt" = plt_1)
> plot.window(xlim = c(0, 1), ylim = c(0, 1))
> box()
> plt_2 <- c(plt_1[2],
> original_plt[2],
> plt_1[4],
> original_plt[4])
> par("plt" = plt_2)
> plot.window(xlim = c(0, 1), ylim = c(0, 1))
> box()
> par("plt" = original_plt)
> box(lty = 2)
> dev.off()
> ########################################
>
> This will draw 3 boxes... one in the lower left corner (specified by
> plt_1), one in the top right corner (specified by plt_2), and one
> dotted box around the full plot box (original_plt).
>
> Now, if you replace the first two box() calls by: rect(0, 0, 1, 1),
> only the lower-left rectangle is drawn.
> If you _add_ rect(0, 0, 1, 1) after each box() call, all boxes and
> rectangles are correctly drawn.
>
> It seems that after setting plt once, subsequent plt alterations put
> the device into a state that will permits drawing of _some_ things
> (e.g. box()), but not other things (e.g. rect, lines, points).
>
> A kludge to fix this is to call box(col = "white")... but
that's quite
> the kludge, indeed!
> Axis() works just like box(), too... but I haven't exhausted which
> drawing functions work and which don't.
>
> I'd classify this is a bug, but I thought I'd check here first.
> I've also only checked this so far with the pdf() device, so I
don't
> know if it is somehow device-specific.
>
> I detected this because some existing code (that worked on some
> earlier version of R, sorry that I don't know which one yet...) has
> suddenly stopped working!
>
> Cheers!
>
> -murat
I believe that what is happening is that the clipping region is being reset when you call box, but not when you call rect. If you insert the command "par(xpd=NA)" (or TRUE instead of NA) after the plot.new and use the rect commands then you can see both rectangles (because this turns the clipping off). Working with the clipping region (indirectly in your case) is complex since some functions properly reset the region and others do not (and making the others automatically reset it may cause other problems when they reset a clipping region that should not be reset). So the options are: 1 dive into the source code enough to figure out if fixing rect to work with the clipping region is simple or not and submitting a patch 2 wait for Prof Brian Ripley to notice this fact and do the above (he has fixed a couple of other functions when made aware) 3 use par(xpd=TRUE) (or NA) to not clip to the plotting region (this is simple, but will allow things to be drawn outside of the plotting region, on simple example is using abline) 4 use a function that properly sets the clipping region (such as box) before plotting anything else 5 call clip(0,1,0,1) (or with the actual user coordinates) to manually set the clipping region 6 other? On Mon, Oct 6, 2014 at 12:00 PM, Murat Tasan <mmuurr at gmail.com> wrote:> Hi all -- I just encountered a behavior that I believe has changed > from previous versions, though I haven't chased back the last version > that behaves as my existing code expects quite yet. > Perhaps this is a bug, though perhaps I'm missing a subtle detail > somewhere in the documentation... > > Here's some code that works as expected (in R 3.1.1): > > ######################################## > pdf() > plot.new() > > original_plt <- par("plt") > > plt_1 <- c(original_plt[1], > original_plt[1] + (original_plt[2] - original_plt[1]) / 2, > original_plt[3], > original_plt[3] + (original_plt[4] - original_plt[3]) / 2) > par("plt" = plt_1) > plot.window(xlim = c(0, 1), ylim = c(0, 1)) > box() > plt_2 <- c(plt_1[2], > original_plt[2], > plt_1[4], > original_plt[4]) > par("plt" = plt_2) > plot.window(xlim = c(0, 1), ylim = c(0, 1)) > box() > par("plt" = original_plt) > box(lty = 2) > dev.off() > ######################################## > > This will draw 3 boxes... one in the lower left corner (specified by > plt_1), one in the top right corner (specified by plt_2), and one > dotted box around the full plot box (original_plt). > > Now, if you replace the first two box() calls by: rect(0, 0, 1, 1), > only the lower-left rectangle is drawn. > If you _add_ rect(0, 0, 1, 1) after each box() call, all boxes and > rectangles are correctly drawn. > > It seems that after setting plt once, subsequent plt alterations put > the device into a state that will permits drawing of _some_ things > (e.g. box()), but not other things (e.g. rect, lines, points). > > A kludge to fix this is to call box(col = "white")... but that's quite > the kludge, indeed! > Axis() works just like box(), too... but I haven't exhausted which > drawing functions work and which don't. > > I'd classify this is a bug, but I thought I'd check here first. > I've also only checked this so far with the pdf() device, so I don't > know if it is somehow device-specific. > > I detected this because some existing code (that worked on some > earlier version of R, sorry that I don't know which one yet...) has > suddenly stopped working! > > Cheers! > > -murat > > ______________________________________________ > R-help at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-help > PLEASE do read the posting guide http://www.R-project.org/posting-guide.html > and provide commented, minimal, self-contained, reproducible code.-- Gregory (Greg) L. Snow Ph.D. 538280 at gmail.com