Thanks again for reviewing.

I pushed the patch here:
http://hg.savannah.gnu.org/hgweb/octave/rev/1830a8f85476

Marking as ready for test.

I was able to reproduce the error on Ubuntu 21.10.

IIUC, the issue was two-fold:
1. A file extension was automatically appended to the temporary file.
2. The syntax for chaining commands is different on Windows and POSIX.

With the attached updated changeset, I'm able to print .emf files on Ubuntu 21.10.
Does that work for you?

(file #52280)

Thanks for testing.

I'm not sure if I correctly understand that error message.
Does it complain about the output being written to a plain file? Does it need to be written to a pipe instead?
Or does it require that the output is written to a plain file, not a pipe?

In the former case, we'd probably need to use a different pipeline dependent on the version of the tools (or the platform or ...?).

In the latter case, could you please show the pipeline (when printing with '-debug')? Where does it still contain a pipe?

For me it doesn't hurt on linux, i.e., after the change ps2edit (3.75 here) doesn't work better (but not worse either :-)) than it did before: it produces a broken FIG file, probably due to an incompatibility with Ghostscript (9.50).
If the patch makes things work on Windows, the only platform where EMF may ever be useful, then I think you should push it (and avoid upgrading either Ghostscript or ps2edit in the future).

oops. Forgot to attach the file.

(file #52260)

"print: 'pstoedit' is required for specified output format, but binary is not available in PATH" (octave installed via snap)

error is probably an issue with snap package.

Having said that, I think we should drop emf format.
People who really need it can save to ps/sv/pdf and use
other tools to convert them to emf.

Currently conversion to emf depends on
ps2edit and ghostscript versions.
In particular, with a recent ghostscript, pstoedit cannot
convert from pdf to fig. From http://www.pstoedit.net/ :

<<<
From version 9.56.0 on GhostScript will probably have a different way of rendering PDF files - see https://ghostscript.com/pdfi.html - and that will break the mechanism used by pstoedit. For a certain time, the old way of reading PDF files will still be included - and then pstoedit could use that legacay mode. But in the longer term, even that will be dropped to my current information.
After that a PDF file will have to be converted to PostScript before it can be processed by pstoedit.

>>>

I can confirm that this is indeed the case at least on my computers (fedora and centos).

Dmitri.
--

@octavian: Could you open a separate bug report with an example of an svg figure that is not imported correctly in LibreOffice? In my experience, LibreOffice handles SVG quite well (on linux at least).

I suspectyour ghostscript is 9.2x. And by "works" you mean that it
produces the same broken fig file in either case.

If I downgrade by ghostscript to 9.25 it "works" too. The fig
file Is wrong/broken (you can open it in xfig) though.
Also my log.txt would say:

cat log.txt
pstoedit: version 3.75 / DLL interface 108 (built: Jul  9 2020 - release build - g++ 8.3.1 20191121 (Red Hat 8.3.1-5) - 64-bit) : Copyright (C) 1993 - 2020 Wolfgang Glunz
   **** Error: can't process embedded font stream,
        attempting to load the font using its name.
               Output may be incorrect.
Warning: falling back to Identity ordering
   **** 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.

Dmitri.
--

The pipe does not work:
cat log.txt
pstoedit: version 3.75 / DLL interface 108 (built: Jul  9 2020 - release build - g++ 8.3.1 20191121 (Red Hat 8.3.1-5) - 64-bit) : Copyright (C) 1993 - 2020 Wolfgang Glunz
Error: /undefined in pstoedit.nameOfOutputFilewithoutpercentD
Operand stack:
   PermitFileWriting
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   --nostringval--   false   1   %stopped_push   1990   1   3   %oparray_pop   1989   1   3   %oparray_pop   1977   1   3   %oparray_pop   1834   1   3   %oparray_pop   --nostringval--   %errorexec_pop   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--
Dictionary stack:
   --dict:1180/1684(G)--   --dict:0/20(G)--   --dict:97/200(L)--
Current allocation mode is local
Current file position is 1263
GPL Ghostscript 9.52: Unrecoverable error, exit code 1
PostScript/PDF Interpreter finished. Return status 256 executed command : gs -q -dDELAYBIND -dWRITESYSTEMDICT -dNODISPLAY -dDELAYSAFER -dNOEPS "/tmp/psinU7Lv2h"
The interpreter seems to have failed, cannot proceed !

See comment 4.
I made t1.pdf
by doing plot(1:10); print("t1.pdf", "-svgconvert").

pstoedit -ssp -f fig "t1.pdf" 2>log.txt | cat
#FIG 3.2
Portrait
Flush left
Inches
Letter
100.00
Single
0
1200 2

If I replace "| cat" with the file, I get a correct fig file.

If I do print("t.emf","-debug") I see:

 opengl-pipeline: '/usr/local/libexec/octave/6.0.1/exec/x86_64-pc-linux-gnu/octave-svgconvert - pdf 95.97 "/usr/local/share/octave/6.0.1/fonts/FreeSans.otf" 1 "/tmp/oct-h5ryZg" ; /usr/local/bin/pstoedit -ssp -f fig "/tmp/oct-h5ryZg" 2> /dev/null | /usr/bin/fig2dev -L emf 2> /dev/null > "t1.emf"'

From pstoedit docs:

Input and outfile file arguments
[ inputfile [outputfile] ]
If neither an input nor an output file is given as argument, pstoedit works as filter reading from standard input and writing to standard output. The special filename "-" can also be used. It represents standard input if it is the first on the command line and standard output if it is the second. So "pstoedit - output.xxx" reads from standard input and writes to output.xxx

I also feel that this thing is getting old.
Now days libreoffice and
I think MS Office supports import of svg files. So perhaps we could just depreciate the emf format.

Dmitri.
--

The current ghostscript version in MXE Octave is 9.5.0. That is also the version bundled with Octave 5.2.0.

pstoedit for Octave on Windows is built with MXE Octave. The version that is currently built is 3.75. That is also the same version that was bundled with Octave 5.2.

I tested on linux. i do not have windows.
The older version did not have this problem, but it will not work
with a newer ghostscript due to some securities issues.

Some  combinations of older gs/pstoedit and they would not work with embedded fonts in pdf.

Dmitri.
--

I am not sure where Windows build gets the pstoedit.
If it is downloads the latest from pstoedit.net
(currently v. 3.75) then the printing to emf will not work.
the pstoedit 3.75 broke i/o redirection, so things like

 pstoedit -ssp -f fig "t1.pdf"   | cat

will not work.
We use this redirection to pipe output of pstoedit to fig2dev.
A possible fix/workaround is to replace pipe with writing to temp file.

Dmitri.
--

It might be a problem with pstoedit. I noticed that

pstoedit -ssp -f fig "t1.pdf" 2> log.txt > t1.fig

crashes ghostscript with

Error: /undefined in pstoedit.nameOfOutputFilewithoutpercentD
Operand stack:
   PermitFileWriting
Execution stack:
   ....

Changing that command  to

pstoedit -ssp -f fig "t1.pdf" t1.fig 2> log.txt

seems to fix it.

Dmitri.
--

The problem descriped in bug #55906 is still open and unresolved.

The following script works fine in 4.4 and older versions.
In 5.1 and 5.2 the resulting emf file ist empty. The old file is overwritten but the size is 0 bytes.

t = 0:0.1:2*pi;
plot (t, cos(t), "-r;cos(t);", t, sin(t), "-b;sin(t);");
print -demf ./OutPlot.emf;

(tested under Windows 10)

As a side note, Octave produce a 0-byte file also 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.

! It is very important for me that printig works. I don't need this on screen only !