Adrian Drury wrote:

The and files on,
dated 2005-11-16, are missing the kpathsea355.dll file from

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

The kpathsea355.dll file was in 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 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


(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)
ntg-context mailing list

Reply via email to