From paul at stat.auckland.ac.nz  Tue Sep 24 04:43:49 2013
From: paul at stat.auckland.ac.nz (Paul Murrell)
Date: Tue, 24 Sep 2013 14:43:49 +1200
Subject: [Rd] inconsistency/bug in recordPlot/replayPlot
In-Reply-To: <CADwqtCNcmxc6XUjjJxcdz91aOKWe-z4vtqhUrxRs_9wQnwcgQw@mail.gmail.com>
References: <CADwqtCNcmxc6XUjjJxcdz91aOKWe-z4vtqhUrxRs_9wQnwcgQw@mail.gmail.com>
Message-ID: <5240FC65.3080402@stat.auckland.ac.nz>

Hi

If you want an explicit background (rather than just relying on what the 
device gives you), you can do something like ...

par(bg="white")
plot(1:10)
recplot = recordPlot()
png("bgreplay.png")
replayPlot(recplot)
dev.off()

Would that satisfy your use case ?

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 at r-project.org mailing list
> 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
paul at stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/



[Rd] inconsistency/bug in recordPlot/replayPlot
Paul Murrell