Thu 20 Jun 2013 05:27:20 PM UTC, comment #13:
Works OK now with 3.6.4_gcc4.6.2 (MinGW), even with no "gs.exe" in %ProgramFiles%/gs<version>/bin/ (Windows XP 32b)
Closing report
|
Thu 20 Jun 2013 03:05:43 AM UTC, comment #12:
Can this bug be closed now? Octave is now searching for both gswin32c.exe and gswin64c.exe. Has anybody been able to verify that things are fixed with the 3.6.4 version of Octave for Windows?
|
Sun 27 May 2012 12:17:24 AM UTC, comment #11:
I forgot to mention, I'm in need of assistance in testing the patch. Any Windows users/developers who have the time, I'd much appreciate the help.
|
Sat 26 May 2012 06:55:37 PM UTC, comment #10:
I've attached a patch which should marginally improve things.
(file #25927)
|
Sat 26 May 2012 06:37:29 PM UTC, comment #9:
I notice that "GS_PROG", instead of "GS", may be used to point to the gs executable.
http://www.werockyourweb.com/install-ghostscript-windows-and-gimp
That can easily be added.
|
Sat 26 May 2012 04:31:43 PM UTC, comment #8:
The "metaphysics" of Windows is a sore spot with me.
I have to put up with it a lot at work. Problems like power point presentations on my desktop not displaying the same on the conference room computer (same OS and same version of PPT). Other examples are EDA tools that run flawlessly on one desktop and crash on an apparently identical desktop.
Even so, I'm confident the "metaphysics" in this example are due to changes to the GSC environment variable, changes to the shell's path, or changes to something independent of Octave (or maybe different versions of Octave).
If the problem is with Octave, it is likely in _print_parse_opts_.m (_ghostscript_binary_). Specifically, the if-block below.
Should "gswin64c.exe" be included as well? Is there a way to distinguish between 32/64 bit Windows ?
|
Sat 26 May 2012 03:32:30 PM UTC, comment #7:
Ben, I'm not sure:
1- I hit the very same bug with Octave > 3.4.0 on Windows
2- There's something fishy about the "automagical" solution (BTW Jordi has made some nice comments on this type of metaphysical software adaptation issues)
3- I don't know if it really is _print_parse_opts_.m, subfunc _ghostscript_binary_ where the actual error occurs. I only found the error msg there, but at the time I didn't dig very hard.
So, my suggestion is to wait until a new Windows binary comes up (3.6.2) and see if this bug still occurs again with it.
As there is an "outside workaround" (bottom of comment #1) I've lowered the priority a bit.
P.
|
Sat 26 May 2012 03:30:32 AM UTC, comment #6:
Philip, from your Apr 06 comment, do I infer correctly that this has been fixed and may be closed ?
|
Fri 06 Apr 2012 10:31:48 AM UTC, comment #5:
This bug is a bit of a intriguing one.
It must have been broken ever since at least 3.4.0, as I've had to copy gswin32c.exe to gs.exe AFAICR.
After digging around in the code, I finally find in _print_parse_opts_.m, subfunction _ghostscript_binary_.m (L.450) that in case of Windows, Octave should indeed search for
{"gs.exe", "gswin32c.exe", "mgs.exe"}
...but no, that didn't work here nor on the OP's box.
However, after having stepped through the code of 3.6.1_MinGW, automagically it now works OK on my box: it does find & use gswin32c.exe. Go figure...
BTW an alternative trick to point Octave to the Ghostscript exe is to specify the fully qualified pathname in an environment var "GSC".
|
Wed 04 Apr 2012 08:23:37 PM UTC, comment #4:
Thanks! That was super quick...
Yes, I am unclear as to the reasoning ( or lack of ) on the part of gs maintainers to not call it gs.exe
The configure flag could work. Again since Octave now supports 32/64 bit Windows, will need an additional check for this as well.
Probably the wiki is the easiest in terms of maintainability. If the gs maintainers change their ways, it would not warrant a source code update in Octave. My two cents... :-)
I will create a new bug report for the "-r0" issue. Yes, it works in 3.2.4 as you confirmed.
Thanks again!
|
Wed 04 Apr 2012 08:09:59 PM UTC, comment #3:
Thanks for reporting back.
Yes this is something for the wiki.
I think the actual, hmm..., "error" lies with the Windows port of ghostscript - AFAIK on other OSes calling "gs" simply invokes the proper executable called "gs", while for reasons perhaps only known to the gs maintainers, in Windows it's called gswin32.exe (GUI) or gswin32c.exe (CLI version).
That said, perhaps some configure flag could be added to Octave, or some stanza like:
or so in _ghostscript_.m (I didn't look yet).
Ugly, yes.
I'll leave this bug report open for in case someone would like to patch _ghostscript_.m (I have no time now).
As to "-r0", I can confirm that one.
Could you please issue a separate bug report for this (OS "any" for the time being)?
I think it is a regression, as it does work OK under octave-3.2.4 but no more in 3.4.3 and up.
|
Wed 04 Apr 2012 07:29:39 PM UTC, comment #2:
Hi Philip,
Thanks for your help. Yes, I did add the subdirectory gs\gs<version>\bin to my path. The "magic" is to copy gswin<32/64>c.exe to gs.exe. I tried that after I filled the bug report. Should not be too hard for Octave to look for the exact file rather than look for gs.exe. If so, ideally it should be documented somewhere... :-)
As an aside, the "-r0" option of print seems to throw an error: _ghostscript_: operator *: nonconformant arguments (op1 is 1x2, op2 is 1x6)
If possible, could you confirm if you see this issue as well? All other numeric values works for the '-rNum' option.
Thanks Again!
|
Wed 04 Apr 2012 05:42:30 PM UTC, comment #1:
"I did install Ghostscript and added it to my Path" - did you add the subdirectory gs\gs<version>\bin to the path or just gs\gs<version>?
(the former is needed)
Just check the actual path in Octave with the command:
strplit (getenv ("PATH"), ";")
For example, what I get is (look at last entry [1,9]):
FWIW, I usually copy the file gswin32c.exe to gs.exe as I suspect that Octave actually looks for a file called gs.exe
|
Tue 03 Apr 2012 10:59:53 PM UTC, original submission:
Hello,
I recently upgraded from 3.2.4 to 3.6.1. Under 3.2.4, print using gnuplot worked without any additional tools. Under 3.6.1, I get the following errors. I did install Ghostscript and added it to my Path. This problem occurs under both 32-bit Win XP and 64-bit Win 7. I installed corresponding 32/64 bit Ghostscript 9.05.
Error reported by Octave:
octave-3.6.1.exe:7> print test.jpg
error: _ghostscript_.m: ghostscript is required.
error: called from:
error: C:\Program Files\Octave-3.6.1\share\octave\3.6.1\m\plot\private\__ghost
script__.m at line 134, column 5
error: C:\Program Files\Octave-3.6.1\share\octave\3.6.1\m\plot\private\__gnupl
ot_print__.m at line 124, column 28
error: C:\Program Files\Octave-3.6.1\share\octave\3.6.1\m\plot\print.m at line
380, column 12
Since I don't have this issue with Octave 3.2.4, I am inclined to think the bug may be specific to Octave 3.6.1
|