kpathsea355.dll missing from 2005-11-16 mswintex.zip and mswincontext.zip

kpathsea355.dll missing from 2005-11-16 mswintex.zip and mswincontext.zip

[Adrian Drury]

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?

Regards,
Adrian Drury

Re: kpathsea355.dll missing from 2005-11-16 mswintex.zip and mswincontext.zip

[Taco Hoekwater]

Adrian Drury wrote:
> 
> For future reference, is this type of issue better tracked in the collector?

 From past experience, this list is most likely the best place.  If it
needs to be in the collector (like this one), it is usually added by
me (some things are resolved so fast that it doesnt make much sense).

Cheers, Taco

Re: kpathsea355.dll missing from 2005-11-16 mswintex.zip and mswincontext.zip

[Hans Hagen]

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)