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

[George N. White III]

On Wed, Aug 25, 2010 at 2:58 PM, Beuthe, Thomas <beuthet at aecl.ca> wrote:
> UNRESTRICTED | ILLIMITÉ
>
>
>>If the tools were configured to use 'tlgs' then dummy packages could install
>>trivial wrappers of the form:
>>
>>$ cat /usr/bin/texlive/2020/bin/<arch>/tlgs
>>
>>#! /bin/sh
>># tlgs -- wrapper to notify users that they need to install gs or
>># edit this script to set "realgs" as required
>>realgs=$(which gs)
>>if [ "${realgs}X" == "X" ] ; then
>>  echo 'Please install ghostscript or edit the tlgs script to set the
>>value of realgs.'
>>  exit 1
>>else
>>  exec "$realgs" "$@"
>>fi
>
>
> In the case of Windows, it didn't start with gs as the problem.
> It was convert that wasn't working at first, and in that case,
> it would be very difficult to tell what's going on in Windows,
> because windows already has a convert command in dos.
> In that case you're hooped, because something executes, it's
> just the wrong something!

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.

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.

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