[Dvipng] Windows MiKTex/TexLive2007 dvipng problems with fonts

[Mark Hammond]

I am trying to generate images of latex formulars via a java

application

and now confronted with some strange problems when using dvipng

bundled

with miktex and texlive 2007 under windows.
The first call of dvipng hangs (generated os-process dvipng.exe via

the

java-application is not responding) because the a sub-process
(makepk.exe for the case that miktex is used as latex-environment)

fails

to generate a certain pk-font. When calling dvipng from the cmd-shell,
then the first run of dvipng leads to a console ouput similar like
METAFONT failed for some reason....
dvipng warning: not all characters could be displayed
and new pk-fonts will be generated from dvipng. A second run of

dvipng,

not changing the contents (the font or font size) of the .tex-files
leads to no warning or errors from dvipng.

I ran into the same issue. What I found is that even if the quiet flag
(-q) is passed to dvipng, miktex-makepk.exe is being invoked with the
-verbose flag. This is causing miktex-makepk.exe to not exit. I was
able to workaround the issue in two steps:

1) When invoking dvipng it is run twice, both times with the quiet,
picky, and strict flags.
2) A wrote a proxy application which took the place of
miktex-makepk.exe. This proxy simply invoked the real makepk after
stripping the --verbose option and replacing it with the -q option.

Those two alterations made a functional workaround.

-Mark

[Jan-Åke Larsson]

METAFONT failed for some reason....
dvipng warning: not all characters could be displayed
and new pk-fonts will be generated from dvipng. A second run of dvipng,
not changing the contents (the font or font size) of the .tex-files
leads to no warning or errors from dvipng.

1) When invoking dvipng it is run twice, both times with the quiet, picky, and strict flags.
2) A wrote a proxy application which took the place of miktex-makepk.exe. This proxy simply invoked the real makepk after stripping the --verbose option and replacing it with the –q option.
Those two alterations made a functional workaround.

This is happening because kpathsea (the TeX path-searching library)
cannot find the appropriate fonts, usually the hang is because it cannot
find _any_ fonts at all. The call to makepk is internal to kpathsea and
not anything that dvipng can influence, which is why the -q flag to
dvipng cannot do anything about the --verbose flag used by kpathsea.

This kind of report has popped up before (when using MIKTeX) and my
suggestion has been to reinstall. My guess is that the affected systems
have everything installed, but the font-searching paths are wrongly set.
I have not before seen the combination of MIKTeX and TeXlive, though.

(In any case, for further hints it would help to know what version of
dvipng you are using, whether it came with MIKTeX or TeXlive, and
whether it is linked to FreeType (best output) or libt1 (fallback) or if
it only has the built-in PK-font support.)

/JÅ

[Mark Hammond]

Post by Jan-Åke Larsson
This is happening because kpathsea (the TeX path-searching library)
cannot find the appropriate fonts, usually the hang is because it cannot
find _any_ fonts at all. The call to makepk is internal to kpathsea and
not anything that dvipng can influence, which is why the -q flag to
dvipng cannot do anything about the --verbose flag used by kpathsea.

MiKTeX seems to be using its own kpathsea emulation wherein directories are set via the MiKTeX Options utility (in the Roots tab). These settings all appear correct, however. The truly odd thing is that if I run dvipdfmx a PDF is generated without error with properly embedded Type 1 font subsets. However yap also generates PK fonts.

Post by Jan-Åke Larsson
This kind of report has popped up before (when using MIKTeX) and my
suggestion has been to reinstall. My guess is that the affected systems
have everything installed, but the font-searching paths are wrongly set.
I have not before seen the combination of MIKTeX and TeXlive, though.

I tested this on two systems, one running Windows Server 2003 and one running Windows XP, both reproduced the issue with complete MiKTeX installations and removal/reinstallation of the complete MiKTeX package.

In my particular case, the issue isn't with TeXlive (that isn't present on either system).

Post by Jan-Åke Larsson
(In any case, for further hints it would help to know what version of
dvipng you are using, whether it came with MIKTeX or TeXlive, and
whether it is linked to FreeType (best output) or libt1 (fallback) or if
it only has the built-in PK-font support.)
/JÅ

This occurs using dvipng 1.12 included with MiKTeX 2.8. I analyzed the executable using dependency walker, and it has a dependency on MIKTEX208-FREETYPE2.DLL.

-Mark

[Jan-Ake Larsson]

Post by Mark Hammond

Post by Jan-Åke Larsson
This is happening because kpathsea (the TeX path-searching library)
cannot find the appropriate fonts, usually the hang is because it cannot
find _any_ fonts at all. The call to makepk is internal to kpathsea and
not anything that dvipng can influence, which is why the -q flag to
dvipng cannot do anything about the --verbose flag used by kpathsea.

MiKTeX seems to be using its own kpathsea emulation wherein directories are set via the MiKTeX Options utility (in the Roots tab). These settings all appear correct, however. The truly odd thing is that if I run dvipdfmx a PDF is generated without error with properly embedded Type 1 font subsets. However yap also generates PK fonts.

OK, that might hint at an explanation. I have very little insight into
how the MiKTeX port finds the fonts. In UNIX-type surroundings one
problem is sometimes that the dvipng binary is not installed in the TeX
tree, while search paths in the kpathsea configuration implicitly
assumes that any calling binary is. Which I have had to fix at configure
time by setting appropriate environment variables within dvipng.

Something similar might have happened in MiKTeX but I cannot help much
here since I don't have a system to test on. Basic problem is that I
don't have the compiler used.

Post by Mark Hammond

Post by Jan-Åke Larsson
This kind of report has popped up before (when using MIKTeX) and my
suggestion has been to reinstall. My guess is that the affected systems
have everything installed, but the font-searching paths are wrongly set.
I have not before seen the combination of MIKTeX and TeXlive, though.

I tested this on two systems, one running Windows Server 2003 and one running Windows XP, both reproduced the issue with complete MiKTeX installations and removal/reinstallation of the complete MiKTeX package.

Hm, and it runs successfully on the second invocation. Seems like a race
or something inside MiKTeX-kpathsea.

Post by Mark Hammond
In my particular case, the issue isn't with TeXlive (that isn't present on either system).

Good, that means that there is no confusion of font search paths between
the two.

Post by Mark Hammond
This occurs using dvipng 1.12 included with MiKTeX 2.8. I analyzed the executable using dependency walker, and it has a dependency on MIKTEX208-FREETYPE2.DLL.

Good, this means it certainly is the process of finding the fonts that
fails and nothing else.

Perhaps I can have a look at the source of the kpathsea emulation to see
what is going on, I dunno. But to do this I need time...

/JÅ

[Mark Hammond]

Post by Jan-Ake Larsson
Hm, and it runs successfully on the second invocation. Seems like a race
or something inside MiKTeX-kpathsea.

I hadn't considered that, but that does seem like a strong possibility (though it is still unclear why it would want to generate PK fonts.)

Post by Jan-Ake Larsson
Good, this means it certainly is the process of finding the fonts that
fails and nothing else.
Perhaps I can have a look at the source of the kpathsea emulation to see
what is going on, I dunno. But to do this I need time...
/JÅ

No worries; the makepk proxy workaround I outlined coupled with invoking dvipng twice is functional.

Let me know if I can provide any information to assist.

Thanks,

-Mark

[Jan-Åke Larsson]

Post by Mark Hammond

Post by Jan-Ake Larsson
Hm, and it runs successfully on the second invocation. Seems like a race
or something inside MiKTeX-kpathsea.

I hadn't considered that, but that does seem like a strong possibility (though it is still unclear why it would want to generate PK fonts.)

It does that because it cannot find fonts. It tries to load T1 fonts
first and when that fails it tries PK fonts. And when kpathsea cannot
find those, it tries to generate them. And when that fails, it seems
that the kpathsea emulation locks up.

/JÅ