Using raster images in plots messes with some graphics parameters

Compare the following code for placing two plots on one page:

tikz('test.tex')
par(mfrow = c(1,2))

image(volcano)
image(volcano)

dev.off()

With this slightly modified version which uses the raster routines:

tikz('test.tex')
par(mfrow = c(1,2))

image(volcano, useRaster = TRUE)
image(volcano, useRaster = TRUE)

dev.off()

Which creates two separate pages with one plot occupying the first half of each page.

It appears that opening a new raster output device and then closing it from within a C function call that is outputting to another device is clashing with the code R uses to track multiple plots, and perhaps other parameters. After some digging with GDB, the culprit seems to be the information contained in dpptr->currentFigure in the base graphics system. The currentPage member is incremented by one each time plot.new is called and a new page is started once it exceeds a value stored by dpptr->lastFigure. To force the creation of a new page, currentFigure is set equal to lastFigure when a new device is opened.

So, it looks like opening a separate raster output device to create PNG images is somehow "bleeding over" to the parameters held by the tikzDevice. The header files required to manipulate dpptr and gpptr are not available to package writers, so there is not much that can be done about this and the raster routine may have to be re-written so that it creates images its self instead of calling back to R.

Possible implementations:

Write a minimal PNG encoder and use it to create files (maintenance overhead)
Use LibPNG (have to write a configure script using autoconf which is a tool I hate)

Also need to ask about this on R-devel in case there are alternate workarounds or the current behavior is a bug in R.

Sharpie / RTikZDevice

Using raster images in plots messes with some graphics parameters #54