Mailing-List: contact cygwin-help@sourceware.cygnus.com; run by ezmlm
Sender: cygwin-owner@sources.redhat.com
Message-ID: <3B415804.8020400@ece.gatech.edu>
Date: Tue, 03 Jul 2001 01:28:36 -0400
From: "Charles S. Wilson" <cwilson@ece.gatech.edu>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.1) Gecko/20010607 Netscape6/6.1b1
MIME-Version: 1.0
To: Robert Collins <robert.collins@itdomain.com.au>
CC: Dmitry Timoshkov <dmitry@baikal.ru>, cygwin@cygwin.com
Subject: Re: Need a ghostscript maintainer
References: <20010628221547.A3873@redhat.com> <20010629174426.C9027@redhat.com> <02bd01c1020a$19687850$c6823bd5@dima> <068c01c1021e$9dccbe80$806410ac@local>
Content-Type: text/plain; charset=KOI8-R; format=flowed
Content-Transfer-Encoding: 7bit

Robert Collins wrote:

> 
> In fact it didn't use to be provided. Users asked for it. Check the
> archives. (Native ghostscript doesn't support cygwin paths for starters &&
> what about X support).
>


Actually, until cygwin-xfree becomes an official part of the 
setup.exe-supported cygwin platform, ghostscript should not be built 
with X support at all.  If ghostscript has X support, then it will 
*require* that users download & install the huge cygwin-xfree package 
(without the assistance of setup.exe) -- or else gs.exe will complain of 
missing dll's.

Thus, the "official" ghostscript package shouldn't have X 
support/dependency.

For the rest of the question, "Why provide a cygwin ghostscript?", 
Jerome's answer is good (paraphrase):

The ability to understand and use unixlike cygwin path constructs, and 
to call gs.exe from scripts are crucial in many cases, especially 'teTeX'.

--Chuck


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/