[tex4ht] [tex-live] TeX4ht does not work properly with default TeXLive Windows install

[George N. White III]

On Thu, Aug 26, 2010 at 11:31 AM, T T <t34www at googlemail.com> wrote:

> On 26 August 2010 12:45, George N. White III <gnwiii at gmail.com> wrote:
>>
>> On reflection I think any scheme that relies on wrappers is doomed to
>> fail -- there are too many places where ghostscript is invoked,
>> different names on different platforms (gswin32c on Windows), and
>> the names are already coded in many places, including 3rd party
>> tools such as convert.
>>
>> There are also problems with providing 3rd party tools.   One of the
>> issues with MiKTeX's ghostscript is that users may have a separate
>> install of ghostscript with added fonts, so eps files using these fonts
>> without embedding can be viewed/converted using the separate
>> ghostscript, but not by MiKTeX's version.
>>
>> In my view, the biggest issue is how to make it clear to end users that
>> "some configuration is required".  Recent examples are ConTeXt
>> MkIV (user needs to run "luatools --generate") and tex4ht (user
>> needs to ensure "*Magick::convert" is available and can find the
>> a suitable ghostscript).   Dummy packages could serve to document
>> the packages that depend on 3rd party tools, and could be replaced
>> with real packages on platforms (mac, windows) where the tools
>> are not widely available.
>
> Management of 3rd party tools is out of scope for us.
>
>> It should also be possible to  provide (architecture dependent)
>> "tlbug" scripts similar to perlbug or octave-bug that would include
>> checks for 3rd party tools.   The script should be designed to be
>> run by the end user in order to document issues with the user's
>> environment, but unlike scripts designed purely for reporting
>> bugs, they should be written in a way that will help users
>> resolve configuration/setup issues before reporting them as
>> bugs.
>>
>> These checks should be "modular", so when tex4ht
>> is installed the checks for ghostscript and convert are enabled,
>> and when ConTeXt is installed a check for whether "luatools --generate"
>> has been run, etc.
>
> Easier said then done.  For example, how can I check whether "luatools
> --generate" has been run?  Or whether installed ghostscript has the
> right fonts?  These kind of things are very package/tool specific and
> often tend to be fragile and change over time.  Who's going to write
> all these checks and keep maintaining and testing them as things
> change?  Your suggestion sounds nice in theory but I don't think it
> would work out in practice.

With the right framework the checks can be improved over time by
the people whose packages need the tools.    Also, there are many
of us whose code is owned by our employers who can't contribute
non-trivial code but can provide "small" patches and bug fixes to
open source projects, so the potential list of contributors is much
larger.

For the luatools question, one test would be to see if
"luatools --find-file mtx-context.lua" returns a non-empty
string.   It isn't perfect (and luatools appears to have
failure modes we don't yet understand), but failure could
be linked to a message "have you run luatools --generate?"
which should get the majority of new users headed in the
right direction.

I suppose this has to be done in perl or maybe lua so it
will run on all the platforms.

>
> Cheers,
>
> Tomek
>



-- 
George N. White III <aa056 at chebucto.ns.ca>
Head of St. Margarets Bay, Nova Scotia