@Rik: Thanks, I pushed the changes:

http://hg.savannah.gnu.org/hgweb/octave/rev/aa9745a1114a
http://hg.savannah.gnu.org/hgweb/octave/rev/1771bed38482

I'll close this report as fixed since the actual regression has been fixed. I could verify today at work that, on Windows, images were not exported to EMF files in previous versions of Octave either.
This is probably a limitation of the fig device as suggested by Dmitri.

From "man pstoedit" :

pstoedit  works  by  redefining  some basic painting operators of Post‐
       Script, e.g. stroke or show (bitmaps drawn by the  image  operator  are
       not supported by all output formats.)

If somebody needs bitmap images I guess the only way is to go svg-->inkscape route.

Dmitri.

This is not perfected yet -- does not work for textures e.g..
(try "demo shading 12 ; print t1.emf"), but seems to work for all
"normal" plots.

Dmitri.
--

The patches applied for me if I did both of them.  I first applied rm_print_formats.patch and then pdf_emf.patch.  Printing a simple plot to emf then worked, as verified with Inkscape.

It seems like the patches should be split so that printing to emf format is restored on stable in the next bug fix release (5.1.1).  And meanwhile, on the development branch the old print formats can be deprecated and maybe a note put in the NEWS file about that.

I attached two patchs:

• rm_print_formats.patch removes documentation and thus official support for a the formats I had proposed here

http://octave.1599824.n4.nabble.com/Drop-support-for-some-print-formats-td4690049.html

• pdf_emf.patch changes the tool chain for fig2dev devices as proposed by Dmitri and fixes.

@Okti: If you wan to test the patch on windows, I also attached print.m and _opengl_print_.m. You'll just need to replace  the ones in your Octave installation (make a backup!) by those.

(file #46550, file #46551, file #46552, file #46553)

This seems like a reasonable suggestion.  We are already creating a toolchain for conversion to EMF so it wouldn't be difficult to change some of the options in that chain and start with pdf rather than eps.

@Okti:

>> Im sorry for this, but under Windows svg isn't well supported.

 
I'm sorry as well but on all other platforms, EMF is not supported at all.
My students often use Windows together with Octave. When they want to make presentations and reports using MSOffice, they use Inkscape to convert SVG to EMF and it works pretty well.
I attached a function file that I use to convert svg to pdf, png, eps using Inkscape. I never tested on Windows but it should be easy to have it work (you'll have to add inkscape's directory, e.g. "C:\Program Files\Inkscape", to your path).
I just extended the function to support EMF and verified that in libreoffice the outpout was good looking.

>> What's the problem about getting it worked like in 4.4?

Understanding why it doesn't work anymore.

Ccing Markus who has much more expertise on Windows.

(file #46546)

The best results (again) can be obtained with inkscape:

+verbose+
octave:1> t = 0:0.1:2*pi;
octave:2> plot (t, cos(t), "-r;cos(t);", t, sin(t), "-b;sin(t);");
octave:3> print t1.svg
-verbose-

and then

+verbose+
inkscape t1.svg --export-emf=t1.emf
-verbose-

File attached.
So may be we just document this route for people who really want
emf file?

Dmitri.
--



(file #46543)

Allegedly, one can get pstoedit to include the font rather than rasterize it (or actually draw with polygons:

http://www.calvina.de/pstoedit/pstoedit#section_12

) but I was not able to do that.

I do not think we could make a good looking emf file on linux.
I am not sure what is better  -- bad looking emf or no emf support at all.

Dmitri.

Why do we need to go through fig2dev? pstoedit supports emf.
I also noticed this:

octave:3> plot(1:10)
octave:4> print teps.eps
octave:5> print tpdf.pdf
octave:6> print -svgconvert tpdf2.pdf

and then

pstoedit teps.eps teps.emf
pstoedit: version 3.73 / DLL interface 108 (built: Jul 24 2018 - release build - g++ 8.1.1 20180712 (Red Hat 8.1.1-5) - 64-bit) : Copyright (C) 1993 - 2018 Wolfgang Glunz
No explicit output format specified - using emf as derived from suffix of output file
Error: /undefined in /findfont
Operand stack:
   --nostringval--   (0)   --nostringval--   0   71.38   31.0183   10   Helvetica
Execution stack:
   %interp_exit   .runexec2   --nostringval--   .findfontop   --nostringval--   2   %stopped_push   --nostringval--   .findfontop   .findfontop   false   1   %stopped_push   2044   1   3   %oparray_pop   2043   1   3   %oparray_pop   2024   1   3   %oparray_pop   1884   1   3   %oparray_pop   --nostringval--   %errorexec_pop   .runexec2   --nostringval--   .findfontop   --nostringval--   2   %stopped_push   --nostringval--   2044   1   3   %oparray_pop   2043   1   3   %oparray_pop   2024   1   3   %oparray_pop   1884   1   3   %oparray_pop   --nostringval--   %errorexec_pop   .runexec2   --nostringval--   .findfontop   --nostringval--   2   %stopped_push   --nostringval--   .findfontop   .findfontop   .findfontop   2066   8   4   %oparray_pop   .findfontop   1975   8   4   %oparray_pop
Dictionary stack:
   --dict:973/1684(ro)(G)--   --dict:0/20(G)--   --dict:312/450(L)--   --dict:42/64(L)--
Current allocation mode is local
Current file position is 5462
GPL Ghostscript 9.26: Unrecoverable error, exit code 1
PostScript/PDF Interpreter finished. Return status 256 executed command : gs -q -dDELAYBIND -dWRITESYSTEMDICT -dNODISPLAY -dNOEPS "/tmp/psinRh9E11"
The interpreter seems to have failed, cannot proceed !

and

pstoedit tpdf.pdf tpdf.emf
pstoedit: version 3.73 / DLL interface 108 (built: Jul 24 2018 - release build - g++ 8.1.1 20180712 (Red Hat 8.1.1-5) - 64-bit) : Copyright (C) 1993 - 2018 Wolfgang Glunz
No explicit output format specified - using emf as derived from suffix of output file
   **** Error reading a content stream. The page may be incomplete.
               Output may be incorrect.
   **** Error: File did not complete the page properly and may be damaged.
               Output may be incorrect.

and

pstoedit tpdf2.pdf tpdf2.emf
pstoedit: version 3.73 / DLL interface 108 (built: Jul 24 2018 - release build - g++ 8.1.1 20180712 (Red Hat 8.1.1-5) - 64-bit) : Copyright (C) 1993 - 2018 Wolfgang Glunz
No explicit output format specified - using emf as derived from suffix of output file

tpdf2.emf is attached. Looks decent.

Dmitri.
--







(file #46531)

Changing Item Group to regression.

Printing to emf format does not work on Linux at all so I can't confirm the observation.

As a side note, Octave does produce a 0-byte file on Linux with no warning that printing failed.  There should at least be a warning/error that printing to EMF is not possible on Linux.