Seems fine to me.

@mdboom, any reason you didn't merge this?

No -- just wanted to give it more time in case anyone else had more comments.

My only question (and this arises out of naiveness of eps) is that it looks like there is eps code that is emitted further up that defines a "showpage" function. Would that cause any conflicts (or is that exactly what is supposed to happen)?

emitted further up that defines a "showpage" function

Indeed, this operator can be redefined. According to eps specification:
The showpage operator is permitted in EPS files because it is present in so
many PostScript language files. Therefore, it is reasonable for an EPS file to
use the showpage operator, although it is not necessary if the EPS file will
only be imported into another document. The application importing the EPS
file is responsible for redefining showpage. showpage may be redefined
using the following code segment:
/showpage { } def

As I understand the situation is following.
The very correct eps file should not contain showpage at its end. It allows to import such files correctly (for example, in some documents). But many eps files actually have showpage at its end. Redefenition like /showpage { } def allows to deal with such not very correct files as it zeros this operator if it's present at the end. Thus, the presence of such operator at the end should not affect importing eps file as a program or library can deal with such redefinition (cairo, inkscape, gs can).

The same is said in following link:
http://paulbourke.net/dataformats/postscript/
"There shouldn't be a showpage, since EPS is designed to be included inside other documents a showpage would obviously ruin the intended effect. In reality most programs that import EPS redefine showpage so that if it does exist it doesn't cause problems, a common definition is "/showpage { } def""