[Rd] Saving R graphics as various file types.

Barry Rowlingson b.rowlingson at lancaster.ac.uk
Wed Jul 18 19:29:58 CEST 2007


  I'm using R called via Rpy from Python running from Quantum GIS.  Put 
simply, I'm developing a GUI wrapper round some R plotting functions.

  What I want to do is offer the user a 'Save Plot As...' option.

  The problem is divining what sort of output files R can copy a 
graphics device into.  The 'capabilities()' function gives a few clues, 
and there should always be postscript and pdf functions, but then if R 
has the Cairo package then there may be even more options - Tiff, SVG 
and so on.

  What I'd like is a way of collecting up all the possible graphics 
output formats so that my Save dialog can list them, and then working 
out how to do the conversions when the user requests it.

  Perhaps someone has already done this? I think the simplest way may be 
to hard-code as much as possible initially.  For each possible output 
format have a number of possible ways of producing that output and a 
test to see if that method is available.  Then run the tests and use the 
best ones found.  For example, it's probably better to make a TIFF file 
using CairoTIFF than using jpeg() and a shell call to ImageMagick's 
convert routine. But if there's no Cairo, fall back. If there's no 
jpeg(), or no ImageMagick, then you're stuck, and jpeg output is no 
longer an option.

  How would this work in practice? Let's think:

  > library(graphicsFormats)
  > graphicsFormats()
  [1] "png" "pdf" "eps" "tiff" "svg"

  > graphicsFormatInfo("png")
  [1] "png ; portable network graphics" "raster"

  > graphicsFormatSupport("jpeg")
  Warning message:
  No jpeg support in capabilities() and no Cairo package present
  [1] FALSE

And then the all important:

  > convertTo("png",filePrefix="/foo/bar")

  I'm still pondering the above functions.  The basic idea would be to 
make graphics file format conversions device driver independent.  I'm 
not sure if this is too lofty a goal, since different device drivers 
will require very different further arguments...

  Anyway, all thoughts welcome.

Barry



More information about the R-devel mailing list