Just tried this from the mercurial snapshot from last night.
fontsrv appears to work but complains about fuse not being set up properly.

Does this mean acme is not going to work?

Should I be asking this on the plan9port mailing list?

On Wed, Jul 8, 2009 at 10:25 PM, Russ Cox <rsc@swtch.com> wrote:

> This conversation reminded me that I have been
> meaning to clean up a program I wrote a while back
> and integrate it into plan9port.  It generates Plan 9
> bitmap fonts on demand using the native window
> system fonts.  Right now it only works on OS X.
> I would gladly accept X11 support and OS X bug fixes.
>
>
>     FONTSRV(4)                                             FONTSRV(4)
>
>     NAME
>          fontsrv - file system access to host fonts
>
>     SYNOPSIS
>          fontsrv [ -m mtpt ] [ -s srvname ]
>
>          fontsrv -p path
>
>     DESCRIPTION
>          Fontsrv presents the host window system's fonts in the stan-
>          dard Plan 9 format (see font(7)). It serves a virtual direc-
>          tory tree mounted at mtpt (if the -m option is given) and
>          posted at srvname (default font).
>
>          The -p option changes fontsrv's behavior: rather than serve
>          a file system, fontsrv prints to standard output the con-
>          tents of the named path. If path names a directory in the
>          served file system, fontsrv lists the directory's contents.
>
>          The fonts are arranged in a two-level tree.  The root con-
>          tains directories named for each system font.  Each font
>          directory contains subdirectories named for a point size and
>          whether the subfonts are anti-aliased: 10 (bitmap) 10a
>          (anti-aliased greyscale) 12, 12a, and so on.  The font
>          directory will synthesize additional sizes on demand: look-
>          ing up 19a will synthesize the 19-point anti-aliased size if
>          possible.  Each size directory contains a font file and sub-
>          font files named x0000.bit, x0100.bit, and so on represent-
>          ing 256-character Unicode ranges.
>
>          Openfont (see graphics(3)) recognizes font paths beginning
>          with /mnt/font and implements them by invoking fontsrv; it
>          need not be running already.
>
>     EXAMPLES
>          List the fonts on the system:
>
>               % fontsrv &
>               % 9p ls font
>
>          or:
>
>               % fontsrv -p .
>
>          Run acme(1) using the operating system's Monaco as the
>          fixed-width font:
>
>               % acme -F /mnt/font/Monaco/13a/font
>
>          Run sam(1) using the same font:
>
>               % font=/mnt/font/Monaco/13a/font sam
>
>     SOURCE
>          /usr/local/plan9/src/cmd/fontsrv
>
>     SEE ALSO
>          font(7)
>
>     BUGS
>          Due to OS X restrictions, fontsrv does not fork itself into
>          the background when serving a user-level file system.
>
>          Fontsrv has no support for X11 fonts; on X11 systems, it
>          will serve an empty top-level directory.
>
>          On OS X, the anti-aliased bitmaps are not perfect.  For
>          example, the lower case r in the subfont
>          Times-Roman/14a/x0000.bit appears truncated on the right and
>          too light overall.
>
>