[tex-live] Re: tex4ht bugfix

Eitan Gurari gurari@cis.ohio-state.edu
Tue, 28 Jan 2003 02:17:30 -0500


Thanks a lot for the input!

The distribution at http://www.xs4all.nl/~infovore/tex4htk.tgz works
beautifully on my platform under "./configure" and "make". 

In the presence of kpathsea, there is no reason for the explicit
t-records in tex4ht.env.  All tex4ht needs is just the information
available to latex about the tfm files, and kpathsea already embeds

If the values for xputenv("TEX4HTFONTSET", "..."); are to come from
the environment file, it is not possible to use this command before
the first call to kpse_find_file() or kpse_open_file().  On the other
hand, tex4ht has its own search engine, and it seems to be
successfully used for the i-records that are provided in the
environment file.

The only issue needing resolution is with regard to the i-records that
provide directions to the htf files:


To my understanding, the value of @texmf@ is known to kpathsea within
some variable (TEXMF?). The value of that variable can be accessed by
tex4ht through kpse_var_value( "TEXMF" ).  So i-records similar to the
following ones may provide to tex4ht the information needed to locate
the files.


Of course, I rather have texht request kpathsea to perform the search,
but I don't know how to request it through a command similar to the
following one.

     extended_kpse_find_file(filename, var, path, ...)

I don't yet follow the details of "client_path" but I suspect it might
provide support for instructions similar to the above.


 > What _may_ work is
 >         xputenv("TEX4HTFONTSET", "{alias,iso8859/2}");
 > which puts the definition into the environment of the current process.
 > (xputenv() is a variant of putenv(3) included in kpathsea.)
 > I think that due to the caching done by kpathsea, you'd have to put
 > these values into the environment before the first call to
 > kpse_find_file() or kpse_open_file().
 > It might make sense to have tex4ht set the "client_path" of the
 > kpse_format_info structures it uses before initializing them.  (I'm
 > open for suggestions for a better -- that is, explainable --
 > interface.)