Mail Archives: cygwin/2005/10/04/04:58:44
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/
- Raw text -