[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