Skip to content

Sweave and X11 on OSX 10.3

6 messages · Friedrich Leisch, Thomas Lumley, Kieran Healy

Kieran Healy
# 
Hi -

I'm running R 1.8.1 (compiled from source) on Mac OS X 10.3 (Panther). I
find that, if Apple's X11 application is not running, Sweave gives an
error when it wants to create a pdf or eps figure. E.g., in the package's
own example-1.Snw file a boxplot is created at chunk 2:

<<fig=TRUE,echo=FALSE>>=
boxplot(Ozone ~ Month, data = airquality)
@

Normally this will create a pdf and an eps version of the boxplot. I get:
Writing to file example-1.tex
Processing code chunks ...
 1 : echo term verbatim
 2 : term verbatim eps pdf
Warning message:
unable to open connection to X11 display`'

Error:  chunk 2
Error in X11(display, width, height, pointsize, gamma, colortype,
maxcubesize,  :
        unable to start device X11

If I start the X11 application, Sweave runs as normal but displays any
figures on an x11() device in addition to creating the eps / pdf files.

I don't remember this happening before and experience teaches me to assume
the issue is with my own setup rather than Sewave. Maybe there's a
problem with the DISPLAY variable, or something that I did while upgrading
to Panther -- but I can't see what it is. Has anyone else had this
issue?

Thanks,

Kieran

--
Kieran Healy, http://www.u.arizona.edu/~kjhealy
Asst Professor, Sociology Dept, University of Arizona.
Friedrich Leisch
# 
> Hi -
  > I'm running R 1.8.1 (compiled from source) on Mac OS X 10.3 (Panther). I
  > find that, if Apple's X11 application is not running, Sweave gives an
  > error when it wants to create a pdf or eps figure. E.g., in the package's
  > own example-1.Snw file a boxplot is created at chunk 2:

  > <<fig=TRUE,echo=FALSE>>=
  > boxplot(Ozone ~ Month, data = airquality)
  > @

  > Normally this will create a pdf and an eps version of the boxplot. I get:

  >> Sweave("example-1.Snw")
  > Writing to file example-1.tex
  > Processing code chunks ...
  >  1 : echo term verbatim
  >  2 : term verbatim eps pdf
  > Warning message:
  > unable to open connection to X11 display`'

  > Error:  chunk 2
  > Error in X11(display, width, height, pointsize, gamma, colortype,
  > maxcubesize,  :
  >         unable to start device X11

  > If I start the X11 application, Sweave runs as normal but displays any
  > figures on an x11() device in addition to creating the eps / pdf files.

  > I don't remember this happening before and experience teaches me to assume
  > the issue is with my own setup rather than Sewave. Maybe there's a
  > problem with the DISPLAY variable, or something that I did while upgrading
  > to Panther -- but I can't see what it is. Has anyone else had this
  > issue?

Your R session has obviously x11() as the default plotting device
... e.g.,

	plot(1:10)

at the prompt should also give an error, if no graphics device is
open. I don't know too much about MacOS X, but having the DISPLAY
variable set without having an X11 server surely means asking for
trouble on Linux, and I guess MacOS X is not different ...
Thomas Lumley
#
On Wed, 7 Jan 2004 Friedrich.Leisch at ci.tuwien.ac.at wrote:

            

      
      
      
    

        
Yes, except there is no excuse for doing this under Linux and there are
good reasons for doing it on OS X.  Under Linux, if you are running X then
all your terminals were probably started after the X server, and they are
usually children of the X root window.  Under OS X the terminals are
usually started independently of X11 and may have been running before the
X server was started.  I don't know any automatic way to have DISPLAY set
correctly when the server is running and unset when it isn't.

The result is that you either need to have DISPLAY set in .tcshrc or
equivalent, or remember to set it when needed.


	-thomas

Thomas Lumley			Assoc. Professor, Biostatistics
tlumley at u.washington.edu	University of Washington, Seattle

  
  


  


      

    

    

      
      

        


  

        

      Friedrich Leisch
    

    

      
      #
    

  


  

          

      
      
      
    

        

        
> On Wed, 7 Jan 2004 Friedrich.Leisch at ci.tuwien.ac.at wrote:

        
>> open. I don't know too much about MacOS X, but having the DISPLAY
  >> variable set without having an X11 server surely means asking for
  >> trouble on Linux, and I guess MacOS X is not different ...
  >> 

  > Yes, except there is no excuse for doing this under Linux and there are
  > good reasons for doing it on OS X.  Under Linux, if you are running X then
  > all your terminals were probably started after the X server, and they are
  > usually children of the X root window.  Under OS X the terminals are
  > usually started independently of X11 and may have been running before the
  > X server was started.  I don't know any automatic way to have DISPLAY set
  > correctly when the server is running and unset when it isn't.

  > The result is that you either need to have DISPLAY set in .tcshrc or
  > equivalent, or remember to set it when needed.

I see, could in this case R for the Mac be smarter about what the
default graphics device should be? This is not an Sweave issue, it
simply means that under the setup described above any call to plot()
---without actively opening a device first---will fail ...

.f

  
  


  


      

    

    

      
      

        


  

        

      Thomas Lumley
    

    

      
      #
    

  


  

      
On Wed, 7 Jan 2004 Friedrich.Leisch at ci.tuwien.ac.at wrote:

            

      
      
      
    

        
R for the mac should probably be less smart. Since options("device") is
set at start-up there isn't much ability to tell what it should be, and we
could just use "postscript" (though "pdf" might be more appropriate on a
Mac).  We have been reluctant to special-case mac code unnecessarily, but
this does indicate a case where it might be necessary.

In the medium term this problem should go away if we get the quartz()
driver working more widely.


	-thomas

  
  


  


      

    

    

      
      

        


  

        

      Kieran Healy
    

    

      
      #
    

  


  

      
I see. Unsetting the DISPLAY variable

 % unset DISPLAY  

solves the problem at the terminal.

Kieran

On 1/8/04 2:52 AM, "Friedrich.Leisch at ci.tuwien.ac.at"

        
<Friedrich.Leisch at ci.tuwien.ac.at> wrote: