David Wolfson wrote:
Unfortunately, the output was not as I'd hope. Instead of getting a
triangle, I have an 'a' in the DVI,
I get the same thing.
and nothing in pdf. This is the same
processing through LyX or LaTeX on the command line.
This appears to be a problem with mktexpk, as if I look at the outputs from
xdvi (rather than running it from gui), I get:
mktexpk: don't know how to create bitmap font for ifgeo10.
kpathsea: Appending font creation commands to missfont.log.
xdvi: Can't find font ifgeo10; using Type1 version of cmr10 instead.
So as I understand it LaTeX now understand ifsym ok and writes the dvi, but
whatever tries to read the dvi (dvips?) doesn't. Does that sound right?
LaTeX writes out a DVI file which contains a command to load the ifgeo10
font. When your DVI viewer (xdvi) tries to load the document, it
discovers that the ifgeo10 font does not (yet) exist in your font
directories, so it tries to run mktexpk to generate the specific font
files. (Fonts are more complicated than I care to get into, but
basically the ifsym package includes font definition files that are
supposed to tell metafont how to generate the needed fonts. I think
mktexpk calls metafont on your system; on my system, it's makepk calling
metafont.) There seems to be a problem with the font definitions
supplied, so metafont fails. After mktexpk returns (unsuccessfully),
xdvi still can't find the needed font, so it substitutes a known font
(cmr10), which produces the 'a' where you expected to find the filled arrow.
You might want to ask on comp.text.tex whether anyone there can figure
out why metafont is failing. (I've looked at the error messages on my
system and can't figure out where the problem exists.) Posting the
contents of the missfont.log file might help.
Paul