On Wed, Aug 25, 2010 at 2:58 PM, Beuthe, Thomas <[email protected]> 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 <[email protected]> Head of St. Margarets Bay, Nova Scotia
