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

[T T]

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.

Cheers,

Tomek