| There are then two problems: dvipng seems not to find the rendered font, and kpathsea takes a long time.
The dvipng problem: I suggest you send me the output of using "dvipng
-d", possibly "-pp 1" or whatever page the problem is on, on the
offending DVI, _via_email_, don't post it on this page. We'll try and
debug this off-list.
The long path-search-time, well, you have a fast machine, right? And
the /home/webwork2 dir is not on NFS, right? (If it is, the PK fonts
are better off in /tmp, which is on the local hard drive=more speed.)
And don't put more in FONTPATH than is necessary. The following is an
excerpt from the info manual of kpathsea.
-----------------------------------------------
Slow path searching
...................
If your program takes an excessively long time to find fonts or other
input files, but does eventually succeed, here are some possible
culprits:
* Most likely, you just have a lot of directories to search, and that
takes a noticeable time. The solution is to create and maintain a
separate `ls-R' file that lists all the files in your main TeX
hierarchy. *Note Filename database::. Kpathsea always uses `ls-R'
if it's present; there's no need to recompile or reconfigure any
of the programs.
* Your recursively-searched directories (e.g.,
`/usr/local/share/texmf/fonts//'), contain a mixture of files and
directories. This prevents Kpathsea from using a useful
optimization (*note Subdirectory expansion::.).
It is best to have only directories (and perhaps a `README') in the
upper levels of the directory structure, and it's very important
to have *only* files, and no subdirectories, in the leaf
directories where the dozens of TFM, PK, or whatever files reside.
In any case, you may find the debugging options helpful in determining
precisely when the disk or network is being pounded. *Note Debugging::.
<| Post or View Comments |> |