It can sometimes happen that dvi2bitmap fails to find fonts,
successfully calls mktexpk to build them, but then still
fails to find them, even though mktexpk has put them where they
should be. There are (at least) three possible reasons for this.
If you are using the kpathsea library, there
might be some misconfiguration which is confusing it. You
can trace kpathsea's deliberations in massive
detail by giving the option -ggp (item `-g, --debug=[spec]').
Perhaps you do not have the kpathsea library
installed, or have disabled it, but you have
requested that font-generation be enabled (see Section 5.1). What happens in this case is
that mktexpk successfully builds the fonts,
and installs them in the correct place, where `correct
place' means `the place where kpathsea would
find them'; you're not using kpathsea, so no
fonts for you. What you have to do in this case is work
out where the `correct place' is (kpsepath
and kpsewhich can help here), and specify
that place using either the -fp option or the
DVI2BITMAP_PK_PATH variable, as above (this
is confusing, I know, but more-or-less unavoidable, since
we are here trying to do kpathsea's job,
without kpathsea).
I think it is also possible to fall victim to a race
condition, where the font is built successfully, but the
program looks for it in the correct place before the font
is fully flushed to disk, or (mumble) something like that.
Simply running dvi2bitmap a second time seems
to work OK. I'm not sure precisely what's going on here,
and I'd welcome more precise observations, here.
Another, slightly nastier reason is as follows.
Some texmf.cnf files declare the location of
the user-writable font directory though a setting like
whereas others have something likeVARTEXFONTS=$SELFAUTOPARENT/var/lib/texmf
Now,VARTEXFONTS=$TEXMFLOCAL/fonts
$SELFAUTOPARENT is a variable which is set by
the kpathsea library to be the grandparent directory of
the executable which uses the library. So, for
/usr/bin/{tex,latex,mktexpk,...}, it's
/, but if your dvi2bitmap binary
doesn't live with the other dvi-ware then its
$SELFAUTOPARENT will be different, so that
dvi2bitmap will look for fonts in a
different place from the place where
mktexpk put them when it successfully
generated them.I would argue fairly strongly that having the
VARTEXFONTS directory depend on the location
of the dvi-ware executables is a very silly thing
to do. This was the case in the teTeX distribution which
came with RedHat 6.0, though this was fixed pretty
rapidly. If you've fallen foul of this, then you can
either
texmf.cnf file to
something more like the second example above; ordvi2bitmap along with the
other TeXware.A third option is to get dvi2bitmap to work
around the problem, by telling it to claim to be some
program which is installed along with the other
dvi-ware. You do this with the
--enable-fake-progname option to the
configuration script (see item `
--enable-fake-progname').