[tex-live] win32 and Gs [was: TL and win32]

[gnwiii at gmail.com]

On 12/22/06, Reinhard Kotucha <reinhard.kotucha at web.de> wrote:
> >>>>> "Staszek" == Staszek Wawrykiewicz <staw at gust.org.pl> writes:
>
>   >> The problem is that the gs installer doesn't work properly.
>
>   > Hmmm, it's a pity, but this problem should go rather to Gs
>   > developers...
>
> Yes, but they have a bug database.  We can place a bug report there
> but I don't expect a fix in a reasonable amount of time.  First, it is
> unclear which priority they assign to the bug report,  and secondly
> they will certainly not change anything which had been released already.
>
> And when the problem is fixed we can probably download stuff from the
> repository and compile it ourselves, but I assume that this is more
> difficult on Windows than on UNIX and you want to avoid it.  I also
> don't know whether everything is under GPL now.  Maybe we have to wait
> for a new GPL release.
>
> On the other hand you called the batch files "sketches".  The UNIX
> shell scripts are not much better.  Maybe I should convert the scripts
> to Perl for next year's TeXLive.



> It seems that there is a lot we have to discuss at the next
> conference.  I like Siep's idea to rename programs to avoid conflicts
> very much.  It is a great advantage to have everything we need for
> TeXlive under our control.

Not if you have to take on extra maintenance.  Didn't 4allTeX try
that? On *n*x you can assume that emacs, perl, ghostscript, ruby, etc.
are available thru the system package management, or in extreme cases
(e.g., legacy RISC machines) can be built outside TL.

One of the lessons from MikTeX is that you have to watch out for
defaults: mgs still has default library path "c:\gs.." which caused
different behaviour depending on whether the user had some (possibly
old, since recent versions install into "Program Files") install in
C:\gs.
This means mucking with the gs build system, not simplying renaming files.

On *n*x there are well-known and widely used configure and built tools
and procedures.  For Win32 you end up with a mix of home-grown build
systems and attempts to adapt *n*x tools that only make things harder.

Many people who have never heard of TeX need a functioning
ghostscript.  From my experiences with pdf2ps, many Win32 users have
difficulties with the command-line tools.  WinEDT provides replacement
for some gs scripts (as both batch files and macros).

It isn't realistic for TL to provide a robust command-line environment
for Win32.  The GNUWin32 project (on sourceforge) does try to provide
comand-line tools to Win32, with qualified success.  For many users,
editor macros can reduce the need for command-line tools.

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