Adrian Drury wrote:

The mswintex.zip and mswincontext.zip files on www.pragma-ade.com, dated 2005-11-16, are missing the kpathsea355.dll file from <root>/tex/texmf-mswin/bin.

I discovered this while trying the URW Garamond installation instructions in the wiki, and the texfont command failed running vptovf.

The kpathsea355.dll file was in mswincontext.zip that I downloaded at the beginning of September, so I copied it from there to my minimal (re)installation (and successfully completed the URW Garamond installation instructions).

For future reference, is this type of issue better tracked in the collector?

is that dll needed? afaik the kpse dll is: tl90kpse.dll maybe you're calling the wrong binary? btw 1: since the kpse library is not that suited for usage outside the tex collection of binaries (the interface changes now and then) i decided to write a ruby variant. since the ruby variants is about as fast as the native c version (or even faster when i auto-dump the file database), in due time i'll let the ruby scripts use this ruby kpse class. A kpsewhich kind of alternative is provided by 'tmftools': tmftools texnansi.enc will provide you the path; this script supports the kpsewhich switched for as much as they make sense. It also tries to locate the cnf file, in the kind of undocumented and fuzzy way of kpse -) An interesting option is tmftools --analyze the idea is that you can locate duplicates, compare trees, etc. i'll document this script when i have time. btw 2: there are all kind of ...tools.rb scripts in the distribution btw 3: when you use texmfstart to start a script, some history of where files are is passed to subprocesses, which means that less calls to kpsewhich need to take place; this is one reason why newtexexec can be a bit more clever and still be faster Hans (if you run over networks, for instance have your tex tree on a nas system, and need to access it like //nas-1/tex , then older binaries may fail due to some problem in kpse; this was repaired recently)