Thanks a ton. quartz(dpi=75) fixes the problem.
On Mar 15, 2010, at 12:57 PM, Simon Urbanek wrote: > Ashwin, > > by default Quartz uses the DPI supplied by your monitors to convert inches to > pixel (X11 ignores the real values). If that doesn't seem to give the right > results for you, try setting dpi to something that makes you comfortable (see > ?quartz and the dpi parameter - it also tells you how to set that > permanently). > > Cheers, > Simon > > > > On Mar 14, 2010, at 16:55 , Ashwin Kapur wrote: > >> Hi all: >> >> Sorry for the resend but after re-revieiwing the mailing list guidelines, it >> seems I'm only supposed to attach pdfs as attachments so I'm resending with >> the screenshots converted to pdfs as opposed to pngs. >> >> I'm having a strange issue with quartz graphics on my mac pro desktop. I'm >> really hoping someone has seen this and knows what's going on because I'm at >> my wits end. >> >> First the details of the machine. >> >> uname -a >> ashwin macpro 10.2.0 Darwin Kernel Version 10.2.0: Tue Nov 3 10:35:19 PST >> 2009; root:xnu-1486.2.11~1/RELEASE_X86_64 x86_64 >> >> R version 2.10.1 (2009-12-14) >> R 2.10.1 GUI 1.31 Leopard build 64-bit (5537) >> The macpro boots to the 64 bit snow leopard kernel. >> >> One fact which might be important is that I have a dual monitor system but >> the two monitors do not have identical resolution. The primary monitor is >> actually a 42 inch 1080P television and the resolution listed by the OS is >> 1080P (Television). The secondary monitor is an old Silicon Graphics >> monitor driven by a SGI Multilink adapter at 1600x1024 which sits on the >> right and closer to me which I use primarily for reading >> documentation/papers etc which I prefer to monitors available today because >> reading it is like reading from paper. >> >> I run R on two macs, my macbook and my macpro. The problem only happens on >> the macpro and only with quartz graphics. If I do an x11() and then plot to >> the x11 window, the problem does not occur. It may be easiest to show the >> problem with screenshots so I'll post them. Hopefully this isn't a breach >> of mailing list etiquette. >> >> To reproduce the problem all l I need to do in a freshly started R GUI >> console is the following. >> >> a <- rnorm(100) >> plot(a) >> >> I can also do this via the command line in a terminal by doing. >> a <- rnorm(100) >> quartz() >> plot(a) >> >> I get the below. The plot is absolutely huge and is clipped below and on >> the right. >> >> <SS1.pdf> >> >> >> If I resize the quarz window by dragging the bottom right window, the >> clipping goes away and subsequent plots are not clipped, but notice how the >> margins and fonts used are huge. >> >> <SS2.pdf> >> >> >> I cannot reproduce the problem on my macbook. I also don't get the problem >> if I use x11() to start up x11 graphics, I get graphics very similar to what >> I get if I plot on one of the machines on my ubuntu based cluster. >> >> >> Below for reference is the output plot(a) produces when run using the x11() >> device. This is very similar to the output produced on the quartz device on >> my laptop. >> >> <SS3.pdf> >> >> >> Another interesting thing to note. When I do demo(graphics) from the R GUI >> Console and it gets to >> >> coplot(lat ~ long | depth, data = quakes, pch = 21, bg = "green3") >> >> It produces the error "Error in plot.new() : figure margins too large" and >> the output: >> >> <SS4.pdf> >> >> >> I've googled/browsed the list etc. One additional issue I notice is that >> >> par()$family is NULL, which was something other had been asked to check but >> setting par(family="mono") doesn't make any difference. >> >> Any suggestions, help, pointers etc would be greatly appreciated. >> >> >> >> _______________________________________________ >> R-SIG-Mac mailing list >> R-SIG-Mac@stat.math.ethz.ch >> https://stat.ethz.ch/mailman/listinfo/r-sig-mac > _______________________________________________ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
