Hi,
I submitted a bug report today.
On 17 April 2010 22:34, Simon Urbanek wrote:
> On Apr 17, 2010, at 2:43 PM, baptiste auguie wrote:
>
>> Hi,
>>
>> On 17 April 2010 18:51, Simon Urbanek wrote:
>>> Baptiste,
>>>
>>> first, there is a mailing list specifically for Mac questions - R-SIG-Mac.
>>>
On Apr 17, 2010, at 2:43 PM, baptiste auguie wrote:
> Hi,
>
> On 17 April 2010 18:51, Simon Urbanek wrote:
>> Baptiste,
>>
>> first, there is a mailing list specifically for Mac questions - R-SIG-Mac.
>>
>
> I wasn't sure if it was Mac-specific (OK, quartz() is but I could not
> test x11()).
Hi,
On 17 April 2010 18:51, Simon Urbanek wrote:
> Baptiste,
>
> first, there is a mailing list specifically for Mac questions - R-SIG-Mac.
>
I wasn't sure if it was Mac-specific (OK, quartz() is but I could not
test x11()).
> Now to your post - grid.cap captures the screen of the device which
Baptiste,
first, there is a mailing list specifically for Mac questions - R-SIG-Mac.
Now to your post - grid.cap captures the screen of the device which has two
implications here:
a) Quartz is asynchronous -- i.e. is doesn't actually draw the content on
screen until you're finished with drawin
I just figured out what the strange "noise" consisted of in the
captured output of my previous example, and this is another source of
curiosity for me,
quartz(width=0.1, height=0.1)
gg <- grid.cap()
dev.new()
grid.raster(gg)
Should grid.cap() really capture the resizing handle of the quartz() win
Dear all,
I am puzzled by the following behavior of the new grid.cap() function,
which appears to run out of time when capturing the output of a
graphic. It works fine if I introduce a Sys.sleep(1) before executing
more code,
library(grid)
quartz()
grid.circle(gp=gpar(fill="black"))
gg <- grid.c
