Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
To: cygwin AT cygwin DOT com
From: Franz Haeuslschmid <lukrez AT gmx DOT at>
Subject:  Re: Cygwin xfig eps problem
Date:  Tue, 04 Oct 2005 10:56:13 +0200
Lines: 148
Message-ID:  <dhtg37$sja$1@sea.gmane.org>
References:  <78ba8be805093011245fd43c27 AT mail DOT gmail DOT com> <dhlj7e$3us$1 AT sea DOT gmane DOT org>  <loom DOT 20051001T151405-153 AT post DOT gmane DOT org>
Mime-Version:  1.0
Content-Type:  text/plain; charset=iso-8859-1
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.5-b22 (cucumber,  windows-nt)
X-IsSubscribed: yes

Mike,

I think I've found the reason for XFig's strange behaviour.  Let
me first reply to your message.

m shi writes:

[...]

> From what I've read, there do seem to be a couple of minor
> variations on a theme here:
>
> 1. Your post does not mention being able to successfully (with
> preview) import the first eps file that you try in a given xfig
> session. Are you able to? I was initially not able to, until I
> changed my system temp path (BOTH windows and cygwin) to a
> directory without spaces in the complete path (instead of
> windows' ridiculous default location in "\Documents/ and/
> Settings"

Yes, I am able to import at least once (as XFig is running) an
EPS file.  And I didn't need to change my path.  Did you try to
mount `$TEMP' (the MS Windows environment variable) on `/tmp'?

> 2. The other post you mention describes gs from the command
> line not liking a /tmp path for -sOutputfile. I have tried from
> the command line, and my gs outputs fine to /tmp (which is the
> manner in which xfig appears to refer to the file). I have
> tried the scripts proposed by Igor in that thread, (with both
> cygwin's gs and gswin32c) and they do not change the behavior I
> am seeing.

That how I tried to originally solve my problem. Deeper in that
thread, it is reported that XFig fails when importing an EPS as
it cannot read the preview.  I just wanted to point out this
thread to show, that out problem is already known.  However, at
that point of time, the original poster could not supply enough
information to extract the problem.

> I think it does have something to do with file permissions -
> perhaps the gs spawned by xfig has a user that our systems do
> not know anything about (but which exists by default on *nix
> systems), and therefore the .pix file is somehow invalid. Are
> you using NTFS for the partition containing your /tmp
> directory?  Perhaps also it only affects installations using
> NTFS since other windows filesystems don't care about security
> so much, and perhaps that is why not everyone sees the same
> behavior? (Just speculating here.) I use XP Home, so I do not
> have a "Security" tab unless I use safe mode - maybe I'll try
> that now to see if I can get any more information.

It has indeed to do with file permissions, however `gs' is
innocent.  XFig may be solely responsible for leaving a file
without permissions.  On the other hand, it may be up to the
functions `fclose' and `unlink'.  Let's see how this comes.

As I'm curious by nature, I decided to inspect XFig's sources.
The function `bitmap_from_gs' in file `f_readeps.c' has the task
to create the command for executing `gs' with appropriate
arguments for generating the preview and finally to call it.  It
then reads the preview from the temporary file for further
processing.  The following excerpt should show the relevant parts
of the function causing the trouble:

/* Read bitmap from gs, return True if success */
Boolean
    bitmap_from_gs(file, filetype, pic, urx, llx, ury, lly, pdf_flag)
    FILE       *file;
        int         filetype;
        F_pic      *pic;
        int         urx, llx, ury, lly;
        int         pdf_flag;
{
    char        buf[300];
    FILE       *tmpfp, *pixfile, *gsfile;
    char       *psnam, *driver;
    int         status, wid, ht, nbitmap;
    char        tmpfile[PATH_MAX],
		pixnam[PATH_MAX],
		errnam[PATH_MAX],
		gscom[2 * PATH_MAX];

    /* ... */

    /* The file name for the file holding the temporary preview is
    constructed.  The name is stored into `pixnam'. */

    /* ... */

    /* The gs command is prepared.  The resulting preview bitmap
    can then be read from the file referred to by `pixnam'. The
    command is stored into `gsfile'. */

    status = pclose(gsfile);
    if (filetype == 1)
        unlink(tmpfile);
    /* error return from ghostscript, look in error file */
    if (status != 0 || (pixfile = fopen(pixnam, "rb")) == NULL) {
        /* ... */

        /* The message is known.  The second preview is written
        to the same file, for which no permission is set at that
        moment. */
        file_msg("Could not parse %s file with ghostscript: %s",
            pdf_flag ? "PDF" : "EPS", file);

        /* ... */
    }

    /* ... */

    if (tool_cells <= 2 || appres.monochrome) {
        /* For our problem, only the alternative branch is
        relevant. */
    } else {
        FILE       *pcxfile;
        /* ... */
        pcxfile = open_picfile(pixnam, &filtyp, PIPEOK, tmpfile);
        status = _read_pcx(pcxfile, pic);
        /* The following line was inserted by me.  XFig then
        imports EPS as expected! */
        fclose(pcxfile);
        /* ... */
    }
    fclose(pixfile);
    unlink(pixnam);
    /* When you use a debugger and passed this line for the first
    preview, you'll see that the file `pixnam' has no file
    permissions set using the file properties dialog of Windows
    Explorer. */
    unlink(errnam);
    return True;		/* Success */
}

The bottom line is, that two `FILE' objects named `pcxfile' and
`pixfile' are created based on the same temporary file referred
to by `pixnam'.  The function `fclose' is used to close a file
and it is _only_ called for `pixfile'.  The function `unlink' is
used to remove the temporary preview.  At the moment when
`unlink' is called for `pixnam', there still exists a file object
(pcxfile), which hasn't been closed yet.

I'll propose a patch that adds that line for closing `pcxfile'.
On the other hand, I'm wondering why `unlink' doesn't remove the
file as it should do.

Regards,
Franz.


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/