Thu 11 Aug 2016 11:19:22 PM UTC, comment #35:
i agree - no longer an octave issue - it would be nice to submit a bug report to xfig for the issue, but is outside the scope of this ticket.
|
Thu 11 Aug 2016 11:01:19 PM UTC, comment #34:
> As another test, what about an emf file created on Linux and copied to a Windows machine? If that can't be read by MS Paint 10 then it is a problem with fig2dev and we should just stop since that is an upstream problem.
Done.
Test results was as expected:
A resulted emf file was rejected by MS-paint but was accepted by other applications.
> So now it as least consistent with the 3.6.X versions of octave?
AFAIK, yes.
As Rik state that this is no longer an issue that is limited to MS-windows and an issue of supporting application "fig2dev".
I agree with Rik's statement but final decision should be done by John to whom this bug is assigned to.
I tried to access support item of Xfig project on SourceForge site but I could not access there.
|
Thu 11 Aug 2016 03:03:51 PM UTC, comment #33:
And a follow up to comment #32, can we close this report now? The original issue was that no file at all was created. Now, a file is created, but the resulting file may not be 100% emf compliant as MS Paint fails to read it.
As another test, what about an emf file created on Linux and copied to a Windows machine? If that can't be read by MS Paint 10 then it is a problem with fig2dev and we should just stop since that is an upstream problem.
|
Thu 11 Aug 2016 11:46:18 AM UTC, comment #32:
So now it as least consistant with the 3.6.X versions of octave?
|
Thu 11 Aug 2016 08:22:53 AM UTC, comment #31:
I have tried
fig2dev -L emf test.fig testx.emf
by fig2dev embedded on octave-3.6.4 msvc
and fig2dev on cygwin.
The produced emf files were rejected by MS-paint but accepted by other software.
|
Thu 11 Aug 2016 05:57:03 AM UTC, comment #30:
Execute "system bash"
test.emf accepted by MS-paint
test2.emf rejected by MS-paint
So this is fig2dev issue.
|
Thu 11 Aug 2016 04:19:21 AM UTC, comment #29:
Created emf file rejected by MS paint on windows 10.
(Both 64 and 32 bit build.)
But it is accepted by XnView, MS-word 2010, and Libre-Office draw 5.1.4 and inkscape 0.91.
Hmmmm!
|
Wed 10 Aug 2016 11:52:49 AM UTC, comment #28:
On win32 (at least machine) it now creates a non 0 length file, however on trying to display it in paint, it says it is not a valid file
|
Wed 10 Aug 2016 08:58:03 AM UTC, comment #27:
The change to pstoedit for mxe build by John Donoghue
http://hg.octave.org/mxe-octave/rev/cc549d1865cb
seem to fix the issue.
On 64 bit binary of development branch source, now the below works.
produces correct emf file.
|
Tue 26 Jul 2016 03:21:57 PM UTC, comment #26:
Pushed updated transfig http://hg.octave.org/mxe-octave/rev/a7e6025bcb39
Pending change need still for pstoedit
|
Fri 22 Jul 2016 12:09:28 PM UTC, comment #25:
Since we build gs for both win64 and win32, we can probally change pstoedit to use it instead of the others.
Actually, perhaps making it look for envvar of GS first, like it does in Linux would be a good idea.
|
Fri 22 Jul 2016 10:34:25 AM UTC, comment #24:
For octave 4.0.3 32bit (from official site), I copy gs.exe to gswin32c.exe (keeping gs.exe) and I replace fig2dev.exe with that octave-3.6.4 msvc.
plot (1:10)
"save as" to emf gave correct emf file.
and
print(gcf, 'figure1.emf', '-demf', '-debug')
gave correct emf file.
For 64 bit octave, I still have empty emf file.
At least 32 bit, working fig2dev and addition gswin32c.exe solve the issue.
Perhaps we have to apply more patches to pstoedit source if we use gs.exe but not gswin32c.exe
|
Fri 22 Jul 2016 04:18:54 AM UTC, comment #23:
Can't load c:\mingw\gs\bin\gsdll32.dll (possibly due to 32/64 bit mix - will try gswin32c.exe instead
gswin32c.exe is usual ghostscript name for windows but gs.exe on octave for windows.
I remember the below
http://wiki.octave.org/Octave_for_Microsoft_Windows#Printing_.28installing_Ghostscript.29
If the 64 bit version of Ghostscript is installed, Octave will not automatically detect it. To use the 64 bit version an option telling Octave about it must be passed to the print command. For example to produce PDF output for a figure, using the 64 bit version of Ghostscript, the command below may be used.
print -Ggswin64c.exe figure.pdf
|
Thu 21 Jul 2016 09:07:32 PM UTC, comment #22:
For comment #21, that's updating to fig2dev 3.2.6
|
Thu 21 Jul 2016 09:06:26 PM UTC, comment #21:
Out of interest sake, I tried updating to 3.2.6
cat testfig.fig | fig2dev.exe -L emf > testfig2.emf - works in this version
cat testfig.ps | pstoedit.exe -gs /usr/bin/gs.exe -f fig | fig2dev.exe -L emf > testfig.emf - works
Also works! So a step in the right direction.
In octave, print(gcf, 'figure1.emf', '-demf', '-debug') still gives an empty file, but:
Note the '-gs /usr/bin/gs' in pstoedit - without it:
So the zero size emf file appears to be a secondary issue - tis time with pstoedit trying to load the wrong ghostscript.
Looking now at how pstoedit decides to pick what gs to run.
|
Thu 21 Jul 2016 12:06:17 PM UTC, comment #20:
I bet the issue is not being in binary mode when writing to stdout then
|
Thu 21 Jul 2016 11:53:54 AM UTC, comment #19:
Can you also attach the emf file generated from your current vs 3.6.4 version ?
|
Thu 21 Jul 2016 11:06:28 AM UTC, comment #18:
$ C:/Software/Octave-3.6.4/bin/fig2dev -h
fig2dev Version 3.2 Patchlevel 5d
|
Thu 21 Jul 2016 10:25:30 AM UTC, comment #17:
What version of fig2dev is in 3.6.4 ?
|
Wed 20 Jul 2016 11:39:49 PM UTC, comment #16:
Using fig2dev embedded msvc version octave-3.6.4 pipe works
(I have also confirmed that pipe does not work on the current one.)
makes correct output.
I have compared correct emf with broken one using a binary editor.
The broken one have a additional 0x0d code to the correct one.
I delete this additional 0x0d and saved.
Then the file can be open as emf file.
As long as fig2dev on octave-3.6.4 on msvc works correct so that we might fix fig2dev on mingw. (Perhaps need patch)
|
Wed 20 Jul 2016 09:24:27 PM UTC, comment #15:
cat testfig.ps | pstoedit.exe -gs /usr/bin/gs.exe -f fig | fig2dev.exe -L emf > testfig2.emf .... Gives an invalid 3k file
fig2dev.exe -L emf testfig.fig testfig2.emf ..... works
cat testfig.fig | fig2dev.exe -L emf > testfig2.emf gives invalid 3k file
Running cat testfig.fig | fig2dev.exe -L emf .... shows binary ending with string 'fig2dev: error: failed to write EMF header'
Running:
C:\Octave\Octave-4.0.3\bin\fig2dev.exe: option requires an argument -- x
Usage: C:\Octave\Octave-4.0.3\bin\fig2dev.exe [-L language] [-f font] [-s size] [-m scale] [input [output]]
So the windows fig2dev doesn't support pipes ?
|
Wed 20 Jul 2016 09:12:43 PM UTC, comment #14:
In octave doing:
Then via command line:
I can load testfig.emf in paint and it is ok.
I can load testfig.png and it is ok
Running in octave:
I get an empty file.
|
Wed 01 Jun 2016 12:31:46 AM UTC, comment #13:
I come from the below
http://octave.1599824.n4.nabble.com/print-to-emf-issue-on-qt-and-fltk-4-0-on-windows-td4677269.html
creates incorrect emf file.
# But octave-4.0.2 x64 and octave-4.1.0+ x64 gives empty emf file.
# Both two are created by me using mxe-octave.
# I will file this the other item.
I think this is directly related to comment #11:.
If I use fig2dev provided in octave-3.6.4 msvc, it produces correct emf.
Therefore this is fig2dev issue that produced by the mxe-octave as already mentioned.
|
Sun 01 Mar 2015 07:21:15 PM UTC, comment #12:
ok - probally an issue with fig2dev then. I will take a look at some stage
|
Sun 01 Mar 2015 04:00:45 PM UTC, comment #11:
In comment #10, there is a typo. The output format from pstoedit should be '-f fig' rather than '-f fix'.
I can now print a file with the .emf extension, but the resulting file won't load in an EMF viewer (But, it is not 0 bytes).
If I go through the individual steps I get working files along the way until the conversion from .fig format to .emf format.
In Octave,
On command line
Interestingly, I can take the individual files over to Linux and they are correct. tst1.ps displays correctly. xfig shows a rendering of the fig, altough the background is wrong. Finally, if I use fig2dev to convert tst1.fig to a different format, including emf, the resulting file is fine. I think there must be something wrong with fig2dev.exe on the Windows side.
I tried using fig2dev.exe on Windows to convert to other formats and at first it fails because there is no 'gs.exe' in the path. I added 'C:\octave\octave-3.9.1+\bin' to the path and now the command will complete, but none of the outputs are any good.
It's probably not worth figuring this out before the 4.0 release this is a seldom used format.
|
Sun 01 Mar 2015 12:12:21 AM UTC, comment #10:
On running for emf.
A empty test4.emf file is created.
From comment 7.
Created .fig file with a:
Unsupported output format fix
followed by the supported formats (see comment 8)
And
Where I am not sure where c:\mingw\gs\bin\gsdll32.dll or c:\mingw\gs\bin\gswin64c.exe comes from, but neither exists, so need to keep looking.
|
Sat 28 Feb 2015 11:58:17 PM UTC, comment #9:
Current compiled pstoedit in mxe:
|
Fri 27 Feb 2015 09:53:26 PM UTC, comment #8:
Related to this, pstoedit appears to attempt to read every dll in the bin folder and see if they are plugins or not, so it may be loading msys-1.dll when it does not need to.
I have an update I will push that changes where it looks for the plugins and uses libplot that I will push up.
Still no libEMF yet.
|
Thu 26 Feb 2015 04:15:40 AM UTC, comment #7:
Another clue is that the MXE log file for building pstodeit contains these lines
Obviously, we can't have EMF output if libemf is missing. This will require installing another package in the MXE Octave build.
|
Sun 15 Feb 2015 12:12:22 AM UTC, comment #6:
This bug is fairly complicated, and not worth resolving for the 4.0 release.
The first problem is that pstoedit, the first command in a pipeline chain, fails to run with
Searching the web this seems to be because the base library file msys-1.0.dll was not compiled to be position independent. I downloaded a rebase.exe utility and executed
This allows the pstoedit command to run. When I do
the command apparently succeeds. But if you look at the file it actually contains an error message. The error message says the fig file format is not supported. In fact, the range of file formats is incredibly small.
On linux, using pstoedit -help I and extracting the reference to fig
This seems to difficult, and too inconsequential, to solve for the 4.0 release.
However, if we get around to it it seems that we need to compile msys with a position independent flag and then we needto check about adding libplot support to MXE Octave. I've added John D. to the CC list just so he knows about this issue.
|
Wed 04 Feb 2015 06:25:08 AM UTC, comment #5:
Works on Linux, still fails in Windows.
|
Sat 11 Jan 2014 10:18:59 PM UTC, comment #4:
Fails for me with an MXE build of the current 3.8.0 release. Could be due to this error (pstoedit is called as part of the pipeline for fltk):
|
Tue 18 Jun 2013 02:38:40 PM UTC, comment #3:
I have the same problem with version 3.6.4: No file is produced when the graphics_toolkit is fltk. Gnuplot works.
Here is output from your suggested test, after I removed "2> NUL" from the print.m command to see the error:
The pstoedit.exe command seems to be specified correctly by the full path to the pstoedit subdirectory. I can't figure out why it's getting stuck here.
|
Fri 18 Jan 2013 01:54:12 PM UTC, comment #2:
Are you using the MinGW, MSys or cygwin build?
Which backend are you using?
If FLTK, try switching to gnuplot:
$ graphics_toolkit gnuplot
$ print("test3.emf")
please post the output (after a fresh start from octave) of
$ graphics_toolkit
$ plot(1:10)
$ print("-debug","test4.emf")
you can then see the commands which are run and try to run them on a console if you want to debug this yourself.
Regards, Andy
|
Fri 14 Sep 2012 01:58:16 AM UTC, comment #1:
Confirming this behaviour with 3.6.2 on XP SP3.
No output produced using these commands:
plot([1 2],[3 6]);
print(gcf,'test_emf','-demf');
print(gcf,'test_meta','-demf');
These devices work OK: ps2, eps2, tex, aifm, dxf, hpgl, png, jpg, svg, pdf.
|
Wed 08 Aug 2012 09:41:16 AM UTC, original submission:
Using Octave 3.6.2 on Windows
print(1, 'figure1.emf')
Nothing happens when using saveas and print to save a plot in figure(1) as .emf or meta formats
However saveas and print works for .bmp, .gif .jpg and the files are saved correctly (but process is slow)
No issues when using older version 3.2.x
|