David Bobroff wrote:
>
> I recently set up emTeX for myself. I then installed OpusTeX. I put the
> various files where it seemed they needed to go and then I called up
> <docopus.dvi>. As expected, Metafont started up and generated all the
> fonts and then the .dvi file displayed juts fine. Now, however, every time
> I open <docopus.dvi> Metafont starts up and generates a font. It goes by
> very quickly but I managed to see that it was calling for cmbx10.mf. I
> found a file called <cmbx10.747> on c:\temp. I have no idea what this file
> is. It seems to be binary.
>
The file cmbx10.747 looks like a Metafont 'gf' file - this is the
bitmapped font data that Metafont produces, and that should normally
be converted by GFtoPK into a '.pk' file. emTeX's 'mfjob' program
normally takes care of the conversion, and moves the resulting file
out of the temporary directory, and deletes the '.gf' file created by
Metafont. (NB, the '.gf' file doesn't have extension '.gf' for Dos
8+3 file naming reasons...)
I guess that what has happened is that Metafont has produced an error
while processing font cmbx10 (scaled to resolution 747dpi), and that
has caused mfjob to abort without finishing the font production.
If you can watch what Metafont does, you may see a message like
'strange error (turning path is zero)' or some such. This is a
relatively harmless Metafont error message, and you can instruct
emTeX's mfjob to ignore it by setting the Dos environment variable
MFJOBOPT to '/i' before viewing/printing the '.dvi' file. (Check what
MFJOBOPT is set to first - if you are using a 386/486/586, it will
probably be set to '/3', in which case reset it to '/3 /i'.)
If you cannot read the Metafont errors before they scroll off screen,
you can look for the log file that it leaves behind. I *think* that
'mfjob' creates a directory called something like 'mfjNNNNN.tmp' in
the temporary directory for holding this log file.
But this is all assuming an emTeX setup like my own, which yours may
not be....
Andrew Gray