Under firefox, you get an error like:

Error: uncaught exception:
[Exception... "Operation is not supported"  code: "9"
 nsresult: "0x80530009 (NS_ERROR_DOM_NOT_SUPPORTED_ERR)"
 location: "http://www.google.com/recaptcha/api/challenge?k=xxx Line: 12"]

While under Chrome it’s

Uncaught TypeError: Object #<a Document> has no method 'write'
api.recaptcha.net/challengek=xxx

The default javascript API uses document.write, which isn’t a DOM method and hence is not a method of true XML documents. It’s not a new issue either, wp-recaptcha has had a history of breaking XHTML. The thing is, the WordPress plugin (which uses the PHP library by the recaptcha people) has an option to “Be XHTML 1.0 Strict compliant”; but this only fixes the use of iframes!

The real solution is to use the reCAPTCHA AJAX API, which for whatever reason isn’t exposed in the PHP library. You can grab my xml fix for wp-recaptcha from github.

Updated: pushed fork to github

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

There was an interesting paper on deriving the algorithm as a result of applying fully-lazy evaluation and memoization on a more naive algorithm. Unfortunately, applying fully-lazy evaluation and memoization to a function in Haskell is non-trivial (despite it being theoretically possible for the compiler to do so!).

It’s always interesting trying to find the functional equivalent to an imperative algorithm. I ended up using some cute Haskell tricks.

Instead of a BFS to compute the failure function, I propagate a recursive function forward as the trie is constructed. The separate mkRoot provides the base case with which to tie-the-knot.

mkRoot xs = let root = Root (edge [] (sort xs) root) in root
mkTrie prefix f xs = Node goto prefix ((not.null) self) f
  where
    goto = edge prefix kids =<< (failTo f)
    (self, kids) = if null (head xs) then ([head xs], tail xs) else ([], xs)

Instead of using a list to implement the branches of a rose tree, I used partial-application over edge. This certainly looks elegant, but in fact it is the weak point, as withPrefix is a linear search; the imperative approach is an O(1) lookup (with small alphabets) or O(log m) over m branches. Furthermore, the lazy evaluation of edge means that the trie is being constantly reconstructed as it is traversed by the automaton.

data Trie = Node (Char -> Maybe Trie) String Bool Trie
          | Root (Char -> Maybe Trie)

edge :: String -> [String] -> Trie -> Char -> Maybe Trie
edge prefix xs f c =
  if null (withPrefix c)
  then Nothing
  else Just (mkTrie (c:prefix) f (map tail (withPrefix c)))
  where
    withPrefix c = takeWhile ((c==) . head) . dropWhile ((c>) . head) $ xs

Overall it doesn’t run too bad (25 seconds on scud with 50 pathological patterns and 100K of input, compiling with ghc -O2). Obviously it’s not generic over types or anything, but it should work fine with lists of types other than Char.

• 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.