Fri 20 Feb 2015 05:25:55 PM UTC, comment #61:
Fix for pread/pwrite issue is here:
|
Thu 19 Feb 2015 07:09:19 PM UTC, comment #60:
OK, thanks for testing. The fix for binary open is confirmed then, and I'll have ghostscript developers close their associated bug report. Also, I should open a new bug report at ghostscript bugzilla for the pread/pwrite. I will do this later today.
|
Thu 19 Feb 2015 01:31:54 PM UTC, comment #59:
Issues in the mingw build with the latest pre-release 9.16 code.
The latest gp_unifs.cpp uses pread/pwrite that are not available in mingw, and so need replacement functions defined.
|
Wed 18 Feb 2015 06:14:59 PM UTC, comment #58:
ghostscript developers have updated their repository and requested someone test.
I've found a couple ways to get the source. The git ghostscript repository is quite big. Also, ghostscript is the gs subdirectory of a bigger project. To get a snapshot of the head of just the gs subdirectory, go to
(Or just sort of navigate around the "tree" from the changeset diff listed above until within the "gs" subdirectory.) When within the source tree for the "gs" subdirectory, look for the widget that says "snapshot" at the second or third line on the page. That will give you a tar file to use.
Extract the archive then run "autogen.sh" within the source code. I ran into a problem in which none of the automake tools were visible, e.g.,:
I created links for the following three utilities:
and "autogen.sh" followed by "configure" (probably redundant) followed by "make" worked for me.
All I need to do to test in Octave environment is rename my "/usr/bin/gs" file and create a link to the newly generated "gs" executable.
Please let me know if anyone else has compilation problems and needs to make the fix I did.
If one wants the whole repository, try:
Again, that takes a while to download and is between 100 and 200 MB worth.
|
Tue 17 Feb 2015 09:52:46 PM UTC, comment #57:
Done.
|
Tue 17 Feb 2015 12:07:58 PM UTC, comment #56:
Sounds like a volunteer to me!
|
Tue 17 Feb 2015 04:10:57 AM UTC, comment #55:
From "gs -h", ghostscript bugs can be reported here:
bugs.ghostscript.com
Requires a bugzilla account. If no one else wants to, I'll report the missing pre-process conditional.
|
Tue 17 Feb 2015 12:25:20 AM UTC, comment #54:
Marking bug as fixed and closing report.
I still have been able to segfault Octave on a Windows XP machine when trying various print combinations, but I'll have to see if I can make it reproducible. I'll open up a new bug report if I can.
|
Tue 17 Feb 2015 12:09:03 AM UTC, comment #53:
Pushed http://hg.octave.org/mxe-octave/rev/50f11d938045
|
Mon 16 Feb 2015 10:33:19 PM UTC, comment #52:
Just tested the patch and it works for me so I think it can be committed.
As for the eps format, jwe hates checking version numbers. The best way is to test capabilities. For that, I think using 'gs -h' and strfind are the way to go.
I checked in a changeset that does that here (http://hg.savannah.gnu.org/hgweb/octave/rev/abc158e7122e).
|
Mon 16 Feb 2015 08:11:52 PM UTC, comment #51:
Or in _ghostscript_.m, before using the opts.device:
|
Mon 16 Feb 2015 07:55:21 PM UTC, comment #50:
what about something like:
|
Mon 16 Feb 2015 06:50:47 PM UTC, comment #49:
OK, nice.
For the 9.15 version I compiled, I see from "gs -h" that eps2write is in the list but epswrite is not in the list. For 8.71 I see epswrite, but no eps2write. So neither of those device names covers both cases, and yes we'll have to condition on the ghostscript version. If that info hasn't already been determined somewhere in the source code, the following grabs the version on my system:
|
Mon 16 Feb 2015 05:08:37 PM UTC, comment #48:
yep - works for me still - updated patch for current mxe repo, including removing old ghostscript patch for gnu-Linux.
All image formats I tried work for me except for eps as per comment 39.
(file #33103)
|
Mon 16 Feb 2015 02:03:38 AM UTC, comment #47:
Or make the conditional the same as what they've used:
as, like you say, it does seem incomplete. If that works, we'll alert gs developers about a possible bug.
|
Mon 16 Feb 2015 01:53:10 AM UTC, comment #46:
Checking the output of mingw gcc, it is defined as 1 in the preprocessor output.
However sometimes gp_fmode_wb etc has been used, and in other places gp_fmode_binary_suffix is obviously being used, so they have a partial implementation going for mingw with regards to binary mode.
should do the trick I hope.
|
Mon 16 Feb 2015 01:46:20 AM UTC, comment #45:
"Perhaps just defining gp_fmode_binary_suffix differently for mingw?"
That would have been my thought. If defining _MINGW32_ to 1 doesn't fix ghostscript. Perhaps creating a file gp_mingw.c that tweaks settings in gp_unifn.c and then patching the Makefile to include gp_mingw.$(OBJ) instead is better? Not worth too much extra effort though, and hopefully the _MINGW32_ path works.
|
Mon 16 Feb 2015 01:36:20 AM UTC, comment #44:
Sure enough. Dependence on the numerical value of a definition isn't commonly done.
|
Mon 16 Feb 2015 01:30:17 AM UTC, comment #43:
Interestingsly, already in gp_unifn.c:
I guess _MINGW32_ is not defined as 1 though
|
Mon 16 Feb 2015 01:25:04 AM UTC, comment #42:
I originally tried making it include the gp_mswin.c stuff, however that led to lots more compile errors.
gp_msdos appears to have some DOS interrupt calls in it, which wont work in Windows.
And using configure appeared to pull in the unix files and appeared convoluted with the way they have implmented variaus make files that are pulled from which seems every which way. Compiling for visual c has its own makefile, which of course isnt even remotely compatible with gnu make.
I had decided then the easiest way was using the unix files as they already compiled ok - although were broken.
Currently it is added as a patch that will only be applied if compiling for mingw. But I will take a look and see if it can be applied differently.
Perhaps just defining gp_fmode_binary_suffix differently for mingw?
|
Mon 16 Feb 2015 12:51:59 AM UTC, comment #41:
I see your modification. Seems like the right idea, and glad it works. It's not the most portable across ghostscript versions, however. Is there another way of accomplishing this?
For example, the first code hunk
already has some kind of binary switch option in the ghostscript code, here:
So, all that is needed is for "gp_fmode_binary_suffix" to be defined to "b", as is the case for several operating systems:
It seems to me that MXE should be using base/gp_dosfs.c. Is that correct? In your previous post you mentioned something about the MXE build using Unix functions/libraries. How can the compilation be made to use the DOS-oriented files?
The second code hunk you changed, I'm not sure about. It's the same idea, but for some reason doesn't have the suffix addition code. Then again, maybe that is done upstream somewhere. I do see
used in several locations. So, I'd say try configuring the compilation so that base/gp_dosfs.c is compiled and its object file included. For example, on my linux system (again, linux) I see the file obj/gp_unifn.o but no other gp_*.o file from that group above that contain gp_fmode_binary_suffix definitions. I would think on the MXE build there should be only a file obj/gp_dosfs.obj.
|
Sun 15 Feb 2015 09:45:16 PM UTC, comment #40:
Pushed http://hg.octave.org/mxe-octave/rev/1a2fec9962a7
|
Sun 15 Feb 2015 08:23:31 PM UTC, comment #39:
Work fine for me, very good job!
surf(peaks) & print was tested on Windows-7,
with Qt, fltk & gnuplot, print -dps & print -dpsc.
However, print -deps does not work:
The default device for eps should be eps2write, but what
about users with older version of GS, without eps2write device?
Should the default device be depend on GS version?
|
Sun 15 Feb 2015 06:17:39 PM UTC, comment #38:
This (attached) appears to work for me.
(file #33084)
|
Sun 15 Feb 2015 05:54:41 PM UTC, comment #37:
Using the idea of binary mode, I think I have it - will post patch in a few ...
|
Sun 15 Feb 2015 05:35:47 PM UTC, comment #36:
Raising the severity of this bug to Blocker for the 4.0 release. Currently we don't have a way to print on Windows.
|
Sun 15 Feb 2015 03:30:56 PM UTC, comment #35:
No O_BINARY appears in the logs, however usr/i686-w64-mingw32/include/fcntl.h has a #define in it
Looking at some warnings from the compile that may be clues:
So it is calling the unix sources rather than anything from the VC++/DOS win32.
Also:
|
Sun 15 Feb 2015 09:36:10 AM UTC, comment #34:
OK, let me retract my statement about binary write (read) being a red herring, step back and say not sure, could be. :-)
If one looks at the garbage data, if it were the case that gp_ftell_64() (i.e., ultimately ftell) were to indicate a file size larger than the actual size (or the correct size but data is decoded when processed), there could be a last pass of this loop:
which grabs garbage data. An fread() is used, and if that file pointer is associated with a non-binary file, ftell may not match the length of the file if, say, <CR> are tossed in decoding.
I've tried to follow backward through the ghostscript code where the open() is for "gx_device * dev", but because of the use of function pointers in a structure it's difficult to search.
Here is one routine I notice (if ultimately it is used, I'm not sure):
I see in my configuration file
Does -DO_BINARY=0 appear in the MXE build configuration?
|
Sun 15 Feb 2015 03:18:48 AM UTC, comment #33:
I think this binary write() is a red herring. One reason is that the data between %%EndResource and %%EndProlog is different for the a1.ps and a2.ps examples.
The second reason is that I've compiled ghostscript 9.15 and tried following the flow of events in the code by writing some comments into the EPS file. Here is the a2.ps code where we see problems:
By use of comments, I've traced this down to the following code hunk inside gdevpdf.c:
That %%EndProlog above is the one written write after the garbage data. Notice above the code where %%EndProlog is written is the output routine pdf_copy_data(). Let's look at that one:
OK, with those comments, what I'm seeing in the data is %%JUST WROTE TO STREAM throughout the whole generated EPS file. In other words, the pdf_copy_data() is used both before and after the %%EndProlog. So, I have to conclude the routine is fundamentally sound, because if it weren't we wouldn't be able to fix the broken EPS file by removing the garbage data between %%EndResource and %%EndProlog. There's be bad data throughout the file.
Right before that %%EndProlog it appears that some resource data is being put in place. Where does that come from? Are there some resource files somewhere that are to be put at the head of the PostScript file? Font descriptions? Default formating? I don't know. I'm still trying to figure out how things are pieced together with Octave/ghostscript.
So obviously this pdf_copy_data() is getting data from some bogus location and copying it into the output file. What could it be? Maybe
1) Some bad data in one of the resource locations? Is MXE missing some resource file? But the garbage data is different in both examples, so not likely.
2) This hunk of code might be dodgy:
Notice how there really is no check on the validity of the file stream. The gp_ftell_64() is supposed to indicate the length of the file, I guess. gp_fseek_64() is setting the file pointer to the head of the file, presumably. But what if that rfile pointer is not valid? In that case gp_fseek_64() would return an error value, in theory. There really should be a conditional test, e.g.,
Of course, if res_end is reported as zero, then no problems. But I notice that the gp_fseek_64 and gp_ftell_64 routines are very system dependent:
I'm wondering if something is not working exactly correctly with the above file routines on MXE.
Let's assume that some bogus file makes it to the point of pdf_copy_data(). There is another chance to catch the issue, in that routine:
If the read doesn't produce any data (because maybe the "file" pointer is bogus), an error is noted and then returned. So for bogus data to get through (assuming it isn't originating from the file's contents) the value of r reported back needs to be 1 or greater. Maybe on MXE that is a meaningless value for a bogus file, while on linux a value of zero comes back for a bogus file.
Just speculating, but I think I'm sniffing more in the general area now. If someone on MXE can make this change
and recompile and see if that fixes the problem, maybe it will lead somewhere.
|
Sun 15 Feb 2015 12:31:05 AM UTC, comment #32:
Yes binary open with write() could be the issue. Let's look at what that "garbage" data is. I extracted that hunk of 16 bytes, then read it into Octave. Here is what that 16 bytes of data is:
Thinking that write() might be displaying 4 characters as 32-bit float, or 8 characters as 16-bit unsinged, I tried reading in the data with all combinations of float/int/32-bit/16-bit/big-endian/little-endian. Nothing seems to make sense. There is some repetition, for sure.
|
Sat 14 Feb 2015 09:23:54 PM UTC, comment #31:
On looking around, I have had some references around about mingw open not being in binary mode vs linux, which was causing extra bytes within files ghostscript at one stage, but it wasnt clear if it is still an issue, which I thought may have something to do with it, but hadnt found dug further into that yet - but would potentally be related then to issues with write at that point.
I will try a recompile and take a look at the log - I would think it should complain about /p being an invalid escale code if thats the issue (I hope)
|
Sat 14 Feb 2015 08:59:48 PM UTC, comment #30:
Good little bit of investigation with the extra 16 bytes...
I've attempted a download of the source code for ghostscript at the website downloads.ghostscript.com. Just to not overlook something, my experience is that the tar expansion reported an error on the file ghostscript-9.15.tar.gz:
while it appears that most of the files expanded in the directory. Using bunzip2 on the file ghostscript-9.15.tar.bz2 produced no errors about the archive.
OK, so I'm looking at the code in the bunzip directory version, and I will toss out some observations that might lead to ideas.
I see five occurrences of "EndResource" in what looks like it could be file generation code (I've snipped results from the many postscript examples in the tree):
1) In gdevpsu.c the following is intended to be printed at that point where the 16 "garbage" bytes are appearing:
In the sample postscript file, I've replaced the garbage bytes with "/pagesave null def" and the PostScript file is readable by "gv". Could it be that under MXE compilation (remember, I'm clueless about MXE), that the "/p" portion of that string is treated as some kind of escape character causing the printf statement to put out some bogus characters? (The string is 18 characters long, minus "/p" makes it 16 characters.) Could MXE require two slashes, "//pagesave null def"?
2) In gdevpsfm.c is the following:
which doesn't look pertinent. There's no EOF right after EndResource in the sample file.
3) In gdevpdfu.c is
There is an "endobj\n" just previous to the %%EndResource in the sample file. Just previous to the "endobj" is ">>", that appears in a function called pdf_store_page_resources:
This (gdvpdfu.c) is starting to look like the path the ghostscript program is taking when creating the sample EPS file. So where does "pdf_write_resource_objects()" go, because that is where the garbage bytes would be? Basically, it calls:
and cos_write_object (in gdevpdfo.c) utilizes
which is
Whew, getting deep. And pco is a structure. And cos_procs is a structure of functions(??), for which write() is called.
I can't follow beyond that point. I could compile the program and print out some of what is being produced here, but if the problem only happens under MXE, then there's no point. I would say though that this structure function call and object pointer stuff is pretty complex, so it wouldn't surprise me a compiler has problems, if that in fact ends up being the issue.
4) In cmsps2.c is the following code hunk:
That doesn't look pertinent. There's no "CR End" in the sample EPS file.
5) In dscparse.c there looks to be a check against EndResource:
I think this is the parsing file for reading postscript input, not generating output.
So, sorry if that was lengthy, and didn't really resolve anything, but I think the warmest trail is #3 above. If there is someone who can compile under MXE and put some fprintf(stderr,) calls in precise locations involving that pco->cos_procs->write(pco, pdev, object_id);, it might go somewhere.
...
OK, wait. Just a little more. Where might this "cos_write" come from? I see a header file ijs/unistd.h that has the following:
which has a WIN3D precompile conditional. So, basically, could it be that after all the structure deciphering, the plain old "write()" command for the compiler is called? Note that all the other ASCII in that test file, the "endobj", the "%%EndResource", etc. is done using stream_puts() whereas that little bit of garbage data between %%EndResource and %%EndProlog looks like it may be originating from write() instead via what I described in #3.
So, MXE's write() routine... any thoughts?
|
Thu 12 Feb 2015 09:31:36 PM UTC, comment #29:
If you remove the 16 characters between %%EndComments and
%%BeginProlog, the file appears valid. (At least when I remove them with vi I can then display the file ok)
So just have to work out what is adding those 16 bytes...
|
Wed 11 Feb 2015 09:16:55 PM UTC, comment #28:
I believe their distributions are created via VC++
|
Wed 11 Feb 2015 05:17:50 PM UTC, comment #27:
Bummer. So there is some magic about how ghostscript gets compiled. Is there a way to ask, or figure out, how the binaries at downloads.ghostscript.com are generated?
|
Wed 11 Feb 2015 11:16:36 AM UTC, comment #26:
I just did a native mingw compile of ghostscript and it has the same issues creating [e]ps files so it looks like an issue with mingw build rather than any cross compiling.
|
Tue 10 Feb 2015 07:55:01 PM UTC, comment #25:
As I wrote, the patch created gs915, but print command creates postscript file with error. If I put in the bin directory
gs 915 + dll, it create a correct file.
Both files are attached, (gs_915mxe.ps is the one created by
mxe octave and gs_915.ps is the file create by windows ghostscript).
The only difference between them are 16 (grabage?) characters in
line 8220, before %%EndProlog
More remarks:
1. print -deps does not work, since gs 9.15 does not have epswrite device.
2. print-deps2write works, but create bugos file with gs_mxe,
and correct file with original gs 9.15
Even in natual Windows-XP (not vitrual) "surf (peaks)" causes
crashes (not allways).
|
Tue 10 Feb 2015 12:41:27 AM UTC, comment #24:
So other outputs appear to function correctly expect those using eps2write ?
|
Mon 09 Feb 2015 09:09:14 PM UTC, comment #23:
It seems that there is a problem with the MXE gs, because if we use original gs it works fine.
|
Mon 09 Feb 2015 09:06:49 PM UTC, comment #22:
I did check it. Unfortunaley, it did not work.
The postscript file has errors:
The postscript file is attached (gs_915.ps)
|
Mon 09 Feb 2015 08:37:30 PM UTC, comment #21:
I'll have to let Avinoam test this. Printing workings for simple images, but the exact sequence with "surf (peaks)" causes a segfault. This could be just my very ancient Windows XP virtual machine.
|
Mon 09 Feb 2015 01:19:13 PM UTC, comment #20:
Another patch for ghostscript 9.15 - it compiles - I haven't had time to run it with anything.
(file #33038)
|
Sun 08 Feb 2015 10:06:23 PM UTC, comment #19:
I had the same results as Rik:
I could compile ghostscript 9.10 with John's patch, but
the result ps file was buggy (attached as gs_910mxe.ps).
Using original ghostscript 9.10, I got a better result (gs_910win.ps), though with a minor bug,
(%BeginResource was written instead of %BeginResource)
which was fixed in version 9.14.
As Rik suggested, I think also that we should consider ver. 9.15
BTW, the new gs 9.10 solves bug 44185.
(file #33034, file #33035)
|
Sun 08 Feb 2015 07:52:28 PM UTC, comment #18:
I checked in a cset for part #2, using del rather than rm to remove files on Windows platforms (http://hg.savannah.gnu.org/hgweb/octave/rev/f1270e5a3117).
Unfortunately, I had no luck with John's build patch for ghostscript 9.10. MXE correctly builds in version 9.10. I can check inside Octave with
However the output is not right. I have a different version of ghostscript 9.10 that I downloaded directly from downloads.ghostscript.com. When I copy over gs.exe from that distribution into the bin directory of Octave it works. Maybe we should just try and move directly to version 9.15 in MXE.
|
Sat 07 Feb 2015 10:18:36 PM UTC, comment #17:
Comment #15 is correct. We have to distinguish between true Windows and Cygwin.
|
Sat 07 Feb 2015 09:09:23 PM UTC, comment #16:
Heres a patch (attached) to build ghostscript 9.10.
It compiled ok, but I havent had time as yet to rebuld my system and verify/see if it works better or worse.
(file #33028)
|
Sat 07 Feb 2015 07:26:25 PM UTC, comment #15:
I believe cygwin (not having used cygwin) ispc = true, isunix = true
|
Sat 07 Feb 2015 07:01:39 PM UTC, comment #14:
I can prepare a changeset.
Just a question:
why not
|
Sat 07 Feb 2015 06:48:23 PM UTC, comment #13:
It seems like this bug should be split into two.
Part 1 is upgrading ghostscript in MXE octave to a recent version with ps2write support.
The second is a bug using Unix 'rm' command on Windows platforms.
I used grep on all of the m-files to find occurrences of rm. See below:
The only file with a problem is _ghostscript_.m. Examples of how to fix it using a conditional test on dos_shell are in _gnuplot_print_.m or print.m. Could someone prepare a changeset for that? We should take care of this before the 4.0 release.
|
Sat 07 Feb 2015 05:30:17 PM UTC, comment #12:
Ah, in _ghostscript_.m. I saw a similar construct in print.m which correctly uses "del" rather than "rm", so that is why I wondered about "dos_shell" value. Do you want to create a changeset for that?
|
Sat 07 Feb 2015 07:33:33 AM UTC, comment #11:
answer to comment #9:
dos_shell is evaluating to "true".
The problem is in __ghostscript__.m.
In lines 150-154
the cleanup_cmd always uses "rm" without checking if it is unix or dos. It works well becuase MXE-octave has rm.exe in the bin directory.
|
Sat 07 Feb 2015 05:48:31 AM UTC, comment #10:
I just tested with the installed ghostscript version of 9.07 and version 9.10 that I downloaded directly and copied into the Octave bin directory. The newer edition works correctly. See also this discussion: http://octave.1599824.n4.nabble.com/mxe-octave-ghostscript-9-07-why-not-9-10-td4665817.html.
The best course of action seems to be to update MXE to use a newer version of ghostscript. I'm adding John D. to the CC list since he does a lot of the work with MXE.
|
Fri 06 Feb 2015 08:36:34 PM UTC, comment #9:
"Note that there is another bug which uses rm instead of del to delete oct-9hn7O3.ps."
So it seems. In other words "dos_shell" is not evaluating to "true" when running under MXE? Is that correct? (I'm not Windows proficient.)
|
Fri 06 Feb 2015 04:07:10 PM UTC, comment #8:
I meant "No, I didn't build..."
|
Fri 06 Feb 2015 04:00:58 PM UTC, comment #7:
No, I did build a new ghostscript to the mxe project
(I wish I knew how to do it...).
I have replaced gs.exe with gs.exe from ver 9.15,
and add directory C:\Octave\Octave-3.8.2\share\ghostscript\9.15
with files from the 9.15 version.
After replacing the gs.exe the print was OK.
|
Fri 06 Feb 2015 01:59:09 PM UTC, comment #6:
@Avinoam: Did you download a binary gs 9.15 built for Windows or did you try adding a new ghostscript 9.15 to the mxe build project? In other words, are you sure that it's the new version that fixes the problem, or is it the mxe cross-compiled version of ghostscript that introduces the problem?
|
Fri 06 Feb 2015 01:28:39 PM UTC, comment #5:
Hi,
file oct-9APtK3.eps is attached. Note that there is another bug
which uses rm instead of del to delete oct-9hn7O3.ps.
gs version bundled with Octave under windows is 9.07.
When I have changed it manually to 9.15 (current version)
the plots where good.
(file #33016)
|
Fri 06 Feb 2015 08:14:44 AM UTC, comment #4:
I've looked at this a bit. You are probably correct that the ghostscript executable is the source of the problem. Clearly what your conversion tool is doing and what my conversion tool is doing are quite different. It looks like your version of the conversion is using compression (e.g., Lempel Ziv)
I've attached a diff file that you can use to display the exact command that is being used as well as to retain the intermediate file. You may then experiment. For example, here is what I see:
My ghostscript is GPL Ghostscript 8.71 (2010-02-10). Perhaps you have a newer version that features better use of compression but may be buggy still.
I would say that if you can read the intermediate file in ghostscript, (e.g., "gv /tmp/oct-ynDS7Y.eps"), yet the output that ghostscript creates is incorrect, then it is likely ghostscript. Maybe try updating your version of ghostscript.
(file #33013)
|
Thu 05 Feb 2015 09:19:38 PM UTC, comment #3:
Now with the files
(file #33004, file #33005)
|
Thu 05 Feb 2015 09:17:56 PM UTC, comment #2:
Both gnuplot & fltk toolkits
a1.ps and a2.ps attached.
If I change the device from ps2write to pswrite I get correct files.
|
Thu 05 Feb 2015 06:41:46 PM UTC, comment #1:
gnuplot graphics toolkit, I assume. Is there some intermediate file that is created? If so, could you please upload an example?
Here is the options:
and up to that point there is nothing in the code that differentiates between PostScript Level 1 and Level 2, so the only difference seems to be the -spswrite and -sps2write. Maybe you could experiment with that outside of Octave/gnuplot.
From a sample PS file, we might be able to detect that something was wrong in the PostScript code regardless of whether an update to ghostscript in mxe-octave solves the problem.
|
Wed 04 Feb 2015 05:33:36 PM UTC, original submission:
When using
print -dps
in windows, the resulting postscript file is displayed as empty
page.
The reason for that is prbably the change from device pswrite to ps2write, which seems to be malfunctioned in version 9.07, the
version of gs bundled with mxe-octave.
There are (at least) two solutions:
1. Change the default device again from ps2write to pswrite (only if ispc ()).
2. Bundle a newer version of ghostscript with mxe-octave.
option 2 will also solve bug 44185
|