Paul,
Thanks for the response.
On Mon, Sep 23, 2013 at 7:43 PM, Paul Murrell <p...@stat.auckland.ac.nz>wrote:
> <snip>
> par(bg="white")
>
> plot(1:10)
> recplot = recordPlot()
> png("bgreplay.png")
> replayPlot(recplot)
> dev.off()
>
> Would that satisfy your use case ?
>
Unfortunately it does not, as my use-case is in a caching/dynamic document
setting. Thus I am capturing plotting from evaluation of an arbitrary piece
of code within a series of such evaluations. I cannot be guaranteed the
code doesn't call dev.off() or explicitly create a new device and I
wouldn't want to clobber any non-white background set in previous code.
I thought putting par(bg="white") after the call to png() (or bg="white" in
the png call) might work, but it appears that replayPlot is actively
setting the background to transparent so that didn't fly.
Any other ideas or advice would be appreciated.
~G
>
> Paul
>
>
> On 09/14/13 09:17, Gabriel Becker wrote:
>
>> Hey all,
>>
>> I've run accross what seems to be a bug in the recordPlot/replayPlot
>> functionality (or at least the lack of a feature which seems pretty
>> reasonable to expect to be there)
>>
>> When drawing to a file-based graphics device (I tested with png()), the
>> file resulting from calling replayPlot on a recordedplot object does not
>> contain an identical image to that captured by the same graphics device
>> when used on the plot that was recorded.
>>
>> Reproducible (at least for me on linux) example:
>>
>> png("noreplay.png")
>> plot(1:10)
>> dev.off()
>>
>> plot(1:10)
>> recplot = recordPlot()
>> png("withreplay.png")
>> replayPlot(recplot)
>> dev.off()
>>
>> The resulting png files are attached. You'll notice that the noreplay.png
>> has the expected white background, while withoutreplay.png has no/a
>> transparent background.
>>
>> This seems likely to be related to the note in ?dev.print :
>> "
>> Note that these functions copy the _device region_ and not a plot:
>> the background colour of the device surface is part of what is
>> copied. Most screen devices default to a transparent background,
>> which is probably not what is needed when copying to a device such
>> as png.
>> "
>>
>> Now this may be as intended because it is "not allowed" to draw
>> recordedplot objects to devices other than the one they were recorded on
>> (AFAIK the primary purpose of recordedplot objects is fast redraws
>> internally), but alas that is what my use-case calls for. Furthermore, I
>> don't think I'm alone in thinking wistfully about how useful it would be
>> to
>> have an actual, transportable object class which can fully represent an R
>> plot in any R-based context.
>>
>> I'm pretty sure I can compile a patch which does this if it would be
>> considered, though there would be a delay of a week or two before I could
>> burrow out from under the mound of other stuff I currently need to be
>> doing
>>
>> sessionInfo below, and I have also confirmed that the behavior remains
>> unchanged in the current trunk.
>>
>> Thanks,
>> ~G
>>
>> sessionInfo()
>>>
>> R version 3.0.1 (2013-05-16)
>> Platform: x86_64-pc-linux-gnu (64-bit)
>>
>> locale:
>> [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
>> [3] LC_TIME=en_US.UTF-8 LC_COLLATE=en_US.UTF-8
>> [5] LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8
>> [7] LC_PAPER=C LC_NAME=C
>> [9] LC_ADDRESS=C LC_TELEPHONE=C
>> [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
>>
>> attached base packages:
>> [1] stats graphics grDevices utils datasets methods base
>>
>> loaded via a namespace (and not attached):
>> [1] compiler_3.0.1 tools_3.0.1
>>
>>
>>
>> ______________________________**________________
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/**listinfo/r-devel<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
> p...@stat.auckland.ac.nz
> http://www.stat.auckland.ac.**nz/~paul/<http://www.stat.auckland.ac.nz/~paul/>
>
--
Gabriel Becker
Graduate Student
Statistics Department
University of California, Davis
[[alternative HTML version deleted]]
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
