running JPEG device on R 1.9.1 using xvfb-run on Linux

On Wed, 12 Oct 2005, David Zhao wrote:

Does anybody have experience in running jpeg device using xvfb-run on
linux? I've been having sporadic problem with: /usr/X11/bin/xvfb-run
/usr/bin/R --no-save < Rinput.txt, with error saying: error in X11
connection. Especially when I run it from a perl script.

Not sure what `xvfb-run on Linux' is, as it is not on my Linux (FC3).
If you Google it you will find a number of problems reported on Debian 
lists.  Here I would suspect timing.

What I do is to run Xvfb on screen 5 by

Xvfb :5 &
setenv DISPLAY :5

and do not have a problem with the jpeg() or png() devices.  I do have a 
problem with the rgl() package, but then I often do on-screen (on both 32- 
and even more so 64-bit FC3).

For R-embedded-in-Python (via RPy) on a Web server, we have been using a
Python programme to automatically start Xvfb if it is not already
running. You can find a copy of the programme in the NetEpi-Analysis
tarball available at
http://sourceforge.net/project/showfiles.php?group_id=123700

The tricky bit is managing the permissions for the Xvfb session,
particularly in a Web server context - you need to take care. However,
this use of Xvfb has been perfectly reliable (on Red Hat Enterprise
Linux 2.1 and 3 with R2.0 and R 2.1)

Is there a better way of doing this? or how can I fix the problem.

You really should update your R.

Yes. We now use GDD, which is an alternative R graphics driver for
raster graphics (Jpeg and PNG), available via CRAN. It allows R to
directly generate jpeg and png files on a Linux or Unix machine without
the need for an X server to be running (not even Xvfb). The quality of
the output is also better than the standard R X11/png/jpeg graphics
device due to the use of anti-aliased fonts by GDD. Earlier versions of
GDD were a bit buggy, but so far we have found the latest version
(0.1.7) to be fine. It is a bit fiddly to install all the libraries it
requires as well as  the recommended (no-cost) Microsoft TrueType fonts,
but the effort is worth it. Many thanks to Simon Urbanek for his work on
GDD.

Tim C