[R-SIG-Mac] Quartz graphics corruption

[Daschbach, John L]

Simon,
    Thanks.  But the original problem, and one that remains, is using
quartz.save() in a source("script.R") operation.  This could still fit your
explanation, but in a script that creates and saves ~50 graphics the
corruption can occur in different entries in the series and for different
numbers of graphics.
    Last time it seemed that saving by hand had better results so that was
what I was doing recently.
    However, my attempts so far at doing the following in a sourced file
have worked.

quartz.save("foo.pdf",type='pdf')
Sys.sleep(2)
quartz.save("goodgraphic.pdf",type='pdf')

It is a real mystery how this is happening I agree.  I think the corrupt
part is always upside down in the pdf output.


-John

On 11/16/07 11:19 AM, "Simon Urbanek" <simon.urbanek at r-project.org> wrote:

> 
> On Nov 16, 2007, at 1:28 PM, Daschbach, John L wrote:
> 
>> 
>> A problem with saving graphics persists through many iterations of
>> the R
>> gui.  I brought this up some time ago but it remains a troubling
>> issue.
>> Often, when saving quartz graphics as PDF the graphic is printed
>> with other
>> screen contents.  Often these are part of the contents of the R
>> console, but
>> upside down.  With the problem earlier it seemed that saving from a
>> print
>> dialog instead of quartz.save(), but currently it is common both
>> places.
>> 
>> Also quite troubling is the printed figure is sometimes missing
>> elements.
>> In the attached figure both problems are evident.  In the one screen
>> quartz
>> window from which this was saved as pdf from a print dialog there is
>> a point
>> at 400 K in the Peak Frequency data, but it is missing in plot.
>> Also note
>> the print through from the console.
>> 
>> For this I moved the console off screen so it physically did not
>> overlap the
>> graphics window.
>> 
>> If there is a work around I would like to know about it.
> 
> 
> The problem appears to have something to do with the interaction of
> the console (i.e. when there is something being printed) with Quartz.
> 
> I have found two work arounds that worked for me:
> 1) issue quartz.save(..) twice. The second output is usually ok.
> 2) use a function to generate and save the graphics.
> 
> The following is just a hypothesis. The key (AFAICS) is that when you
> type quartz.save... and hit <Enter>, the console is being updated (new-
> line) at the same time as the graphics gets plotted which results in
> the corruption (why, that's still a mystery as the corruption does not
> happen on-screen). By issuing two quartz.save commands the second one
> is likely to run after the console was updated, so it doesn't get
> corrupted.
> Analogously, by using a separate function to both plot and save the
> graphics, the saving will occur after the console was updated.
> 
> R-devel (2.7.0 to-be) features a completely new, re-written Quartz
> device that doesn't suffer from this effect, because it uses Quartz
> Extreme instead of Cocoa.
> 
> Cheers,
> Simon
>