Cygwin xfig eps problem

Cygwin xfig eps problem

[Mike Shi]

I'm using xfig (3.2.4 - from a recent (last week) Cygwin install) in
Cygwin on Windows XP Home with NTFS filesystem. I'm having trouble
with importing EPS files into xfig using the "Picture Object" command.
I can import 1 EPS file without problem. However, when I try to import
a second (different) EPS file into the same xfig figure, I get an
error:

"GPL Ghostscript 8.15: **** Could not open the file /tmp/xfig-pic000208.pix"

Initially, I got a similar error whenever the path to my EPS file, OR
the path to my cygwin temp directory contained a space. At that time
it was more of an issue with using cygwin. But now I can import a
single EPS file without fail, every time, and the second and all
subsequent import attempts will fail.

From my investigations to date, it seems that xfig calls ghostscript in
order to generate the on-screen preview image that one sees with xfig.
This process works perfectly for the first EPS import, and I can see
the "xfig-pic000208.pix" file in my system temp directory (although I
cannot access it in any way). From looking at some of the source code,
the "000208" suffix would appear to be coming from the xfig process
ID, which is going to remain the same throughout a single xfig
session, making me think that every eps file import after the first
one tries to write a preview image over the first preview image.

I tried the same thing from a Knoppix distribution (same xfig
version), and everything worked fine. I could not find a .pix file
remaining in my /tmp directory after the EPS import. Therefore, it
seems likely that either xfig or gs is not "clearning up" correctly
after generating the pix file. Possibly a filesystem/permissions
issue, since executing a 'ls' command in the /tmp directory yields:

"ls: xfig-pic001372.pix: No such file or directory"

Any help would be most appreciated. (Ultimately, I'd like to be able
to combine more than one EPS file and mark them up with psfrag tags
for export and use in LaTeX documents.)

Thanks,
Mike

--
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/

Re: Cygwin xfig eps problem

[Franz Haeuslschmid]

Mike,

I'm also affected by this problem.  I know, that "Me too" posts
are evil, but I think, it may by useful to point out older
threads and messages that were discussing this sort of problem.
My article can be found in the mailing list archives discussing
XFree:

  <URL:http://article.gmane.org/gmane.os.cygwin.xfree/14757>

In this message, I was referring to a thread of November 2003,
that also discusses this issue: 

  <URL:http://thread.gmane.org/gmane.os.cygwin/40818>

You may recognize the problems, but I'm afraid that there is no
solution yet proposed.

Mike Shi writes:

[Problem description.]

> Any help would be most appreciated. (Ultimately, I'd like to be able
> to combine more than one EPS file and mark them up with psfrag tags
> for export and use in LaTeX documents.)

My "solution" at that time was to ignore the error messages and
to do without the preview.  I could use the presented bounding
box of the imported object to estimate size and position of the
imported EPS figure.

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/

Re: Cygwin xfig eps problem

[m shi]

Hi Franz - Thanks very much for replying to my post.

Franz Haeuslschmid <lukrez <at> gmx.at> writes:
> I'm also affected by this problem.  I know, that "Me too" posts
> are evil, but I think, it may by useful to point out older
> threads and messages that were discussing this sort of problem.
> My article can be found in the mailing list archives discussing
> XFree:

Well, I don't necessarily think they are "evil", if for no other reason than it
might get some useful dialogue going. Yes I had seen those previous posts, as
well as a couple of others. I had, in fact, considered replying to your post
instead of starting a new thread since it seemed the closest to the problem I'm
seeing.

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"

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.

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.
 
> My "solution" at that time was to ignore the error messages and
> to do without the preview.  I could use the presented bounding
> box of the imported object to estimate size and position of the
> imported EPS figure.
> 
> Regards,
> Franz.

Agreed - this works, and it is of course only the preview that is missing.
(Although I can always get 1 eps file per xfig session with preview correctly
which is ok for a majority of situations.) Another "solution" is to use epstool
to convert eps => fig. It works surprisingly well (quality-wise), but it does
make the task of maintaining graphics for documents one step more complex.

Thanks again for your reply, and would be interested to here on whether your
problem is identical to mine, or slightly different. Cheers,
Mike




--
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/

Re: Cygwin xfig eps problem

[Franz Haeuslschmid]

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/

Re: Cygwin xfig eps problem

[Mike Shi]

Franz Haeuslschmid <lukrez <at> gmx.at> writes:
> 
> Mike,
> 
> I think I've found the reason for XFig's strange behavior.

Franz - Well, you got further with the source than I did!

Once I saw that (a) xfig always created files of the same name (based on the
PID), (b) that file remained throughout the xfig session after an EPS import,
and (c) that I was never able to see the file after doing the same with xfig
running on Linux (since, as you discovered, it should get immediately deleted
once xfig has used it!), I figured it was a windows filesystem/permissions type
problem that was beyond my expertise and that I was unlikely to get much help
with since (i) the majority of xfig users likely run it happily on *nix, and
(ii) it appears that there aren't many cygwin users (i.e. 2 at the moment!) who
find the problem an annoyance ...

BUT, thanks to your curiosity and subsequent investigations, it seems that we
may have an answer.

Franz Haeuslschmid <lukrez <at> gmx.at> writes:
> On the other hand, I'm wondering why `unlink' doesn't remove the
> file as it should do.

I'm afraid I'm not going to be of much help to you here ... ;-)

Looks like I'll have to get the X11 development stuff installed on my box when I
get back to it to try your idea. Thanks for your efforts - I'll let you know how
it goes.

Cheers,
Mike




--
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/

Re: Cygwin xfig eps problem

[Franz Haeuslschmid]

Mike Shi writes:

> Franz Haeuslschmid <lukrez <at> gmx.at> writes:
>> 
>> Mike,
>> 
>> I think I've found the reason for XFig's strange behavior.
>
> Franz - Well, you got further with the source than I did!

It was a great opportunity (and fun) to install Eclipse' CDT and
using Cygwin's tools to build and debug XFig.  And it was further
an incidental opportunity to refresh my knowledge of C/C++ :)

> Once I saw that (a) xfig always created files of the same name
> (based on the PID), (b) that file remained throughout the xfig
> session after an EPS import, and (c) that I was never able to
> see the file after doing the same with xfig running on Linux
> (since, as you discovered, it should get immediately deleted
> once xfig has used it!), I figured it was a windows
> filesystem/permissions type problem that was beyond my
> expertise and that I was unlikely to get much help with since
> (i) the majority of xfig users likely run it happily on *nix,
> and (ii) it appears that there aren't many cygwin users (i.e. 2
> at the moment!) who find the problem an annoyance ...

It may be that other XFig users are running Cygwin on a Windows
98 derivative.  Or use a temporary directory on a FAT partition.
But this is highly speculative right now.

> BUT, thanks to your curiosity and subsequent investigations, it
> seems that we may have an answer.
>
>> On the other hand, I'm wondering why `unlink' doesn't remove
>> the file as it should do.
>
> I'm afraid I'm not going to be of much help to you here ... ;-)

No problem there.  I think I'll suggest a patch in a new thread
to push that topic on top of this list.  There may be a reader
with better knowledge of C/C++ and its functions that can make
clear the issue with `unlink'.  I now even think that `unlink'
finally removes the file, however with a certain delay that is
enough to inhibit XFig from writing to the same file (now without
any file permission).

> Looks like I'll have to get the X11 development stuff installed
> on my box when I get back to it to try your idea. Thanks for
> your efforts - I'll let you know how it goes.

Good luck!
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/

Re: Cygwin xfig eps problem

[Mike Shi]

Franz Haeuslschmid <lukrez <at> gmx.at> writes:

> It may be that other XFig users are running Cygwin on a Windows
> 98 derivative.  Or use a temporary directory on a FAT partition.
> But this is highly speculative right now.

Got a chance to try it - it fails also with a FAT /tmp filesystem.

> Good luck!
> Franz.

Fraz - Perfect! Works a charm! Thanks a bunch again for your efforts!

Cheers,
Mike




--
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/