Xfig 3.2.9a under Cygwin64 on Win11 with gs10.04.0
export correctly eps and ps that can be converted ps2pdf into correct pdf, but
exporting pdf produce the following error message:
Error message from spawned process: /bin/sh: line 1: gs: command not found
Error in ghostcript command,
gs -q -dSAFER -dAutoRotatePages=/None -sDEVICE=pdfwrite -dCompatibilityLevel=1.5 -dPDFSETTINGS=/prepress -o '-' -: No such file or directory
Your help will be hugely appreciated
Andrew
Thank you very much for your prompt response.
As I said below I have ghostscript gs10.04.0 installed that handles
properly exporting postscript but not pdf.
Maybe I have to re-install the gs again.
When I run gs from a shell, I got the error:
Any comments will be most welcome.
Andrew
--
Dr Andrew P Paplinski
Last edit: tkl 2025-02-08
Sounds to me that you have to install the ghostscript package to make this work (gs is the short name of ghostscript).
Does calling fig2dev from the commandline work?
This is what xfig calls when exporting to pdf.
On 9/02/2025 7:57 am, tkl wrote:
It creates an empty *.pdf . where an error message would go?
Andrew
Last edit: tkl 2025-02-09
However, the sequence
produces the perfect pdf file.
Andrew
Last edit: tkl 2025-02-09
The error message should go to stderr, nothing special when calling fig2dev from the commandline. This is strange.
Dear tkl,
I might be on something: I have gs installed in C:\gs\gs10.04.0\bin
However, in the bin directory there is no gs command only gswin64 and
gswin64c
However , xfig needs to find gs .
I tried to put a file called gs in C:\gs\gs10.04.0\bin with a one line
contents gswinc $*
It makes the difference, but not completely:
if I call gs -h from the Cygwin64 Terminal, I can se the correct path:
however, ps2pdf produces an Error: /undefinedfilename in (aa.eps\r)
The question is where the gs command should be and in what a form.
Cheers
Andrew
Last edit: tkl 2025-02-10
Thank you for investigating further. The gs file contains the one line "gswinc", not "gswin64c"? Does Windows expand "gswinc" to find the correct executable?
In the gs file you mentioned, try to put
gswinc "$@". $* expands to all arguments, but splits at each whitespace. The latter form preserves whitespace, if there are, in arguments.Do you compile fig2dev from sources? If so, you could set the name or the entire path to gs at configuration time,
./configure --help prints a one-liner about GSEXE, how to set variables in the first few lines of the help output and the meaning of the variables at the end of the output. Currently, the ./configure script searches for gs, gswin32c, gsos2, gswin32, but not for gswin64c. If this is the underlying issue, the configure script should be modified accordingly. I am quite curious, whether setting GSEXE as above would help.
Yours,
Thomas
Thanks, Thomas
On 10/02/2025 9:00 pm, tkl wrote:
Cheers,
Andrew (from au. current time 21:18)
Last edit: tkl 2025-02-10
To be precise, "$@" enclosed by the quotation marks. Hence, the script should exactly contain
and have the executable bit set,
chmod +x C:\gs\gs10.04.0\bin\gs.Sorry for the adventures; I have looked now at the cygwin package, and it reports a build failure. For the time being, it seems for now there is only the workaround to export from xfig to .eps (or .ps, for a letter- or A4-sized document) and converting manually with ps2pdf to pdf. Improvements to the build-process will likely arrive in cygwin packages only in the next release.
On 10/02/2025 10:38 pm, tkl wrote:
The double quote has made the difference.
Now fig2dev aa.fig aa.pdf
works nicely producing the correct pdf with the bounding box.
In addition :-( , it generates error messages as below that makes no
difference;
In conclusion, I am satisfied and grateful for your help.
Will wait for the next release of cygwin.
Cheers,
Andrew
Last edit: tkl 2025-02-11
Good to hear. Strange errore message, "Unrecoverable error", so gs might write the output file, here aa.pdf, then look for some lib (findlibfile), and fails. Thus findlibfile seems to be unnecessary.
Yours,
Thomas
In any case, there may be an issue similar to the one reported in macports ticket 68751: Xfig does not pass the environment to the spawned process, e.g., a modified PATH. Previously, not sure but probably before version 3.2.9, xfig used popen(), system() and friends. These commands invoke a shell, hence do all the shell initialisation, setting paths etc., and also pass the full environment. I tried by moving gs to a different location and writing a small wrapper script containing "export >/tmp/gs_env".
Xfig does not really need the ghostscript executable, xfig is usually linked to the ghostscript library at build time. However, there is an option and a resource to set the path to the executable: The user rightly should expect that such path is passed to sub-processes; Fig2dev currently calls gs using system() or popen(). I should either link fig2dev to gslib, making gs thus a dependency of fig2dev. Or pass the environment from xfig, and probably also implement an environment variable in fig2dev to allow the user to set the path to gs.
Keeping this ticket open, to remember
- to add gswin64c to the executables searched for during ./configure
- add an environment variable, e.g, FIG2DEV_GS, to give the user the possibility to override the path to ghostscript,
- probably contact cygwin to patch their current xfig distribution.
thanks again :-)
Andrew
On 11/02/2025 8:57 pm, tkl wrote:
Related
Tickets: #189