The situation is this: imagine you have a faceted plot that is tall enough that the x-axis ticks and labels become obscured (e.g. when using a clipped viewport such as a browser window). This is particularly destructive when you’re using an x-scale with manual breaks or a transformation.

library(ggplot2)
g <- ggplot(diamonds, aes(carat, ..density..)) +
   geom_histogram(aes(fill = clarity), binwidth = 0.2) +
   facet_grid(cut ~ .)
print(g)

There simply isn’t a way to repeat the x-axis labels in ggplot2 at the moment without discarding faceting and rendering each facet as a separate ggplot call. I’ve seen some examples of selective plotting used to good effect in combining multiple plots with common elements, but I can’t find anything applicable to keep consistent scales and binning without duplicating a lot of the (internal) facet and bin logic.

Instead my best shot was to clone some of the grob elements and redraw them at different locations:

grob <- ggplotGrob(g)
xtext <- getGrob(grob, "layout::axis_h::axis.text", grep = TRUE)
xtext <- editGrob(xtext, gp = gpar(fontsize = 8))
downViewport("background::panels::layout::axis_h-13-3") # ids from grid.ls()
pushViewport(viewport(y = unit(34, "npc"), name = "axis_h_rep-1"))
 grid.draw(xtext)
popViewport()

Unfortunately I couldn’t find a consistent way of querying the grid graphics internals for the measurements necessary to move the “mirrored” axis labels to the right place. The 34 there is a magic number I found with grid.locator() and trial-and-error; it changes depending on the graphics device. At one point I hoped I could clone the entire axis_h viewport, pry some vertical space from in between the facet panels, and paste the clones in between. Unfortunately grid layouts don’t seem to be very mutable once they’ve been created, and redrawing the text grob seemed like the best I could do to reuse the output.

While looking at the stackoverflow answer for the same problem, I came across Harlan’s assessment:

GGplot’s philosophy is about doing the right thing with a minimum of customization, which means, naturally, that you can’t customize things as much as other packages.

This is more significant when contrasted with the context of R itself; in R, the user retains full control. Coming up against ggplot’s choice of only exposing high-level primitives often leaves the user with the choice of:

• accepting The Way ggplot Does Things and not getting what they want
• waiting for Hadley to write a patch (next summer, if you’re lucky?)
• wading through ggplot internals so you can duplicate its functionality with plyr and grid calls
• abandoning ggplot completely

• vector graphics,
• consistent fonts,
• not to mess around overlaying text in LaTeX,

and maybe typeset math in the R graphics. This post surveys the state of the art in how to achieve the best of all worlds when importing graphics generated by R into documents typeset to PDF with LaTeX. I look at postscript and PDF figures generated by R’s X11, Cairo, and finally the new (and awesome) TikZ devices.

If you’re using some TeX variant, you probably care a lot about the professional presentation of your document. Accordingly, you probably cringe when you see figures in a PDF document that aren’t quite as crisp, or have inferior fonts and math typesetting. Even some of the Use R books fail blatantly in this regard. You’d expect the ggplot2 book to espouse the prettiness of its output, but it has raster figures and an ugly sans-serif font—a prudent optimisation for file size and rendering speed nevertheless.

The traditional way to get R graphics that are consistent with LaTeX fonts was with a LaTeX toolchain via DVI and postscript. You can render R graphics to a postscript device that uses the appropriate TeX encoding, according to the instructions in the R manual for postscript {grDevices}. I usually run ps2eps on the result to fix the bounding box and other issues; you can also use par(mar=) from R according to the manual. In the LaTeX preamble you add \usepackage[T1]{fontenc} and then after the document is typeset and it’s converted from DVI to PDF, the fonts are all magically correct.

However, with some of the new typography features (and the shorter toolchain that doesn’t require ghostscript) available with pdfLaTeX it’s understandable if you want to move away from plain LaTeX. However, when you use pdfTeX, you can’t include EPS graphics.

R is no exception; I’ve always found integrating graphics with pdfLaTeX to be SNAFU. I can personally attest to ipe (if you can get it to build) and asymptote looks good although I’ve yet to try it. Using a metapost intermediate format worked well from gnuplot. xfig is horrible and I detest manually writing any metapost or pstricks.

R can produce PDF output, but R’s basic PDF device doesn’t have the same font family and encoding options as its postscript device: you will get the error unknown family ‘ComputerModern’ if you try to supply the same parameters. There are some amusing suggestions for dealing with this, but a lot of the material that turns up from a google search is outdated.

One workaround I tried was to convert the EPS that worked with the previous LaTeX → DVI → PDF toolchain. However:

• pstopdf results in the correct font, but weird kerning
• ps2pdf results in the correct font, weird kerning, and weird scaling/bounding box issues
• Apple’s Preview.app machinery lost the font information

Instead of using the EPS route, we can just use a similar font that R does support exporting directly to PDF. The Computer Modern – Unicode project has some ports of the Computer Modern family to OpenType, which R can then utilise.

The X11 device (on Mac OS X) works perfectly with par(family="CMU Serif"), but the pdf device again complains that it’s not a postscript font, and even if you try to use postscript versions of Computer Modern directly there is an encoding issue. Paul Murrell has an excellent writeup of using cm-lgc to create PDF output with an alternative encoding for the type 1 CM fonts. I couldn’t get either CairoX11 or CairoPDF to produce output with CM, but I suspect Murrell’s method will fix Cairo too. Quartz works out of the box if you happen to use Mac OS X.

quartz(type="pdf", file="test-quartz.pdf")
par(family="CMU Serif")

Ligatures don’t work, but I can live with that. Quartz even manages to typeset math made with expression, but in a way that will stand out as blindingly ugly in a TeX document.

This all brings us to the true state of the art (FWICS): tikzDevice. This project is still in beta, and their project page has the eerie bareness of archaic Alexandria. Nevertheless, once I figured out how to install it, I was impressed.

# from R
install.packages("filehash")
install.packages("tikzDevice", dependencies=TRUE,
  repos="http://R-Forge.R-project.org",
  type="source")

I took the opportunity to switch from macports’ TeXlive to the MacTeX-derived BasicTeX, and installed a couple of necessary packages:

# from sh
sudo /usr/texbin/tlmgr install pgf preview

It’s as easy as tikz("tikzfig.tex") and your usual plotting commands to generate a figure, then:

% in the preamble:
\usepackage{tikz}
\usepackage{color}
% ...
\begin{document}
% ... then in the body:
\begin{figure}[p]
\input{tikzfig}
\caption{TikZ}
\end{figure}
\end{document}

It processes all the text in the figure with LaTeX, including math marked up with ‘$’s. However, don’t bother using R expressions in your labels: symbols and accents are positioned by R as separate nodes, and would-be TeX specials aren’t even escaped.