Rename and enchance ggplot_to_gtable → plot_to_gtable

[flying-sheep]

plot_grid and friends now also accept default R plots as recordedplot object or function that plots when called.

This PR also contains a few R CMD check fixes in other commits.

Fixes #52

[clauswilke]

Thanks for your effort on this!

Two requests:

• Could you update the plot_grid documentation? You added an example, but in the description on top the text still only talks about ggplot plots and gtables. Also, it would be great to add a paragraph on how to use this option.

• Could you also add a few sentences and an example to the plot_grid vignette?

[flying-sheep]

OK, done

[clauswilke]

Great, thanks!

[clauswilke]

Hey,

I've played around a lot with the recording of base plots, and I've encountered some problems. For example, for plot(sqrt), the axis labels tend to be partially or completely cut off:

p <- function() plot(sqrt)
ggdraw(p)

Also, the plot can affect neighboring plots when used in plot_grid(), even though it shouldn't extend into the neighboring space. See e.g. this example taken from the vignette here:

The legend title is partially cut off. This problem goes away if I swap the two plots, demonstrating that the recorded plot somehow overlaps with the ggplot2 plot.

Not sure where the problem resides, because when I call gridEcho(p) for the above code example the plot looks correct. So the problem has to be somehow in the conversion of the gridEcho() output to a grobTree. Any insight you can provide would be appreciated.

[flying-sheep]

hi, i’m happy to help, but i fear there are too many things i don’t understand.

For example, for plot(sqrt), the axis labels tend to be partially or completely cut off:

p <- function() plot(sqrt)
ggdraw(p)

hmm, doesn’t happen for me. is this happening in RStudio, plain R, or where?

Also, the plot can affect neighboring plots when used in plot_grid(), even though it shouldn't extend into the neighboring space.

why can this happen? i thought plot_grid takes a bunch of gtables or other grid stuff and puts them into a grid. shouldn’t the drawing mechanism prevent that?

[clauswilke]

It seems the problems are slightly different depending on whether I run the code in RStudio or plain R. But there are problems nonetheless. In plain R, this code works as expected:

p <- function() plot(sqrt)
ggdraw(p)

However, when I put the same plot into the plot grid, it doesn't work properly. The axis labels are now missing.

plot_grid(p, p, p, p, scale = .8)

The same happens when I use the draw_plot() function:

ggdraw() + draw_plot(p)

All these functions internally call annotation_custom(). The difference is that the version in ggdraw() leaves the xmin, xmax, ymin, and ymax coordinates at their defaults while draw_plot() sets them to the limits of the coordinate system set up by ggdraw(). So it's some problem with viewports and coordinate system, somewhere in annotation_custom() or deeper in grid.

Btw., grobs can in principle draw outside their assigned area when placed with draw_plot() / annotation_custom(), because ggplot2 doesn't enforce clipping inside the plot area. This could be changed in cowplot, but I don't think clipping is the problem. The problem is that somehow things live at strange coordinates in the grobs created by grid.grabExpr(), possibly at coordinates -Inf or Inf.

[clauswilke]

Indeed, for example the y axis label lives at a negative x coordinate:

So some additional code will be necessary to make sure we capture the complete grob and properly move it into a box that completely encloses it. I'll think about it some more, but would appreciate any additional help you can provide.

[clauswilke]

Ah, one more thing: which parts are cut off seems to depend on the exact size and aspect ratio of the device into which the captured plot is drawn. Do the following experiment. Rerun this code in plain R:

p <- function() plot(sqrt)
ggdraw(p)

and then resize the plot window that pops up. You can see how different parts of the plot are cut off depending on how exactly the window is resized.

[clauswilke]

I'm moving this discussion to issue #69.