bugGNU Octave - Bugs: bug #58702, emf format no longer works for...

 
 

bug #58702: emf format no longer works for printing 2

Submitter:  Ich selber <octavian>
Submitted:  Sat 04 Jul 2020 12:00:43 PM UTC
   
 
Category:  Plotting with OpenGL Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Regression
Status:  Fixed Assigned to:  None
Originator Name:  Octavian Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 16 Nov 2021 07:52:54 PM UTC, comment #31: 

Thanks Markus. Closing report as fixed.

Pantxo Diribarne <pantxo>
Group Member
Tue 16 Nov 2021 11:30:17 AM UTC, comment #30: 

Thanks again for reviewing.

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

Marking as ready for test.

Markus Mützel <mmuetzel>
Group administrator
Sun 14 Nov 2021 09:44:17 PM UTC, comment #29: 

Yes, the latest patch allows me to produce an emf file that can be imported in LibreOffice on linux.

Pantxo Diribarne <pantxo>
Group Member
Sun 14 Nov 2021 09:32:01 PM UTC, comment #28: 

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)

Markus Mützel <mmuetzel>
Group administrator
Sun 14 Nov 2021 08:59:33 PM UTC, comment #27: 

Here it is, "plot (1:10); print -debug toto.emf" leads to:


fig2dev command: '/usr/bin/fig2dev -L emf 2> /dev/null'
svgconvert command: '/media/pantxo/datadisk/dev/octavebuild/src/octave-svgconvert - %s 96.13 "/media/pantxo/datadisk/dev/octavebuild/../octaveclone/etc/fonts/FreeSans.otf" 1 "%s"'
pstoedit command: '/media/pantxo/datadisk/dev/octavebuild/src/octave-svgconvert - %s 96.13 "/media/pantxo/datadisk/dev/octavebuild/../octaveclone/etc/fonts/FreeSans.otf" 1 "%s" ; /usr/bin/pstoedit -ssp -f fig "%s" 2> /dev/null'
opengl-pipeline: '/media/pantxo/datadisk/dev/octavebuild/src/octave-svgconvert - pdf 96.13 "/media/pantxo/datadisk/dev/octavebuild/../octaveclone/etc/fonts/FreeSans.otf" 1 "/tmp/oct-PDIO5r" ; /usr/bin/pstoedit -ssp -f fig "/tmp/oct-PDIO5r" 2> /dev/null "/tmp/oct-Y4sXzH" & /usr/bin/fig2dev -L emf 2> /dev/null "/tmp/oct-Y4sXzH" "toto.emf"'
qt5ct: using qt5ct plugin
warning: print: Aucun fichier ou dossier de ce type, '/tmp/oct-Y4sXzH'
warning: called from
    print at line 799 column 9


The following works well to produce an emf file that LibreOffice correctly imports:


print toto.fig
system "fig2dev -L emf toto.fig toto.emf"


In the current pipeline, the redirection of stderr is misplaced. Instead of "fig2dev -L emf file-in file-out 2>/dev/null" we get
"fig2dev -L emf 2>/dev/null file-in file-out"

Pantxo Diribarne <pantxo>
Group Member
Sun 14 Nov 2021 08:41:06 PM UTC, comment #26: 

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?

Markus Mützel <mmuetzel>
Group administrator
Sun 14 Nov 2021 08:04:40 PM UTC, comment #25: 

Sorry, I just saw that I hadn't applied Markus' patch... Actually after the patch, FIG format is fixed on linux too (xfig can open it and displays a correct figure), but fig2dev complains about


fig2dev: error: fseek() failed.  EMF language requires the output is seekable.
                Output to a plain file, not to a pipe.


Looks like we should also avoid redirection of stdout here.

Pantxo Diribarne <pantxo>
Group Member
Sun 14 Nov 2021 07:52:38 PM UTC, comment #24: 

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).

Pantxo Diribarne <pantxo>
Group Member
Fri 12 Nov 2021 07:19:43 PM UTC, comment #23: 

Markus that's great, people who just want to put some vector graphics into their Word file, will appreciate your patch.

Stefan Pofahl <ellocco>
Fri 12 Nov 2021 02:39:41 PM UTC, comment #22: 

oops. Forgot to attach the file.

(file #52260)

Markus Mützel <mmuetzel>
Group administrator
Fri 12 Nov 2021 02:39:11 PM UTC, comment #21: 

Following what Dmitri wrote in comment #12, I tried to avoid using pipes or redirecting stdout in the printing toolchain.

With the attached changes, printing to .emf (or .fig) files on Windows 10 with Octave 6.4 works for me using the commands from comment #0.

Is that change ok on all platforms?

Markus Mützel <mmuetzel>
Group administrator
Thu 11 Nov 2021 10:52:53 PM UTC, comment #20: 

"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.
--

Dmitri A. Sergatskov <dasergatskov>
Thu 11 Nov 2021 10:02:02 PM UTC, comment #19: 

Octave, v6.4:
emf-export is still not working for "qt" and "fltk".
gnuplot is still operational.
gnuplot is also the only graphics_toolkit that exports pdf
in form of cropped size.
The situation is the same for Linux and MS Windows 10.
If if try to export "emf" the error message under Linux
is: "print: 'pstoedit' is required for specified output format, but binary is not available in PATH" (octave installed via snap)

Stefan Pofahl <ellocco>
Sun 02 Aug 2020 07:00:59 PM UTC, comment #18: 

@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).

Pantxo Diribarne <pantxo>
Group Member
Thu 23 Jul 2020 07:35:52 PM UTC, comment #17: 

Hi Dimitri,

I'm using LibreOffice and of course I have tested SVG as a replacement of EMF but unfortunatly the support is not quite well and the results are quite bad.
The best supported vector format is EMF on windows by many programs. It is the native way.
So it would be important to keep this format still working.

Ich selber <octavian>
Fri 10 Jul 2020 04:57:54 AM UTC, comment #16: 

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.
--

Dmitri A. Sergatskov <dasergatskov>
Fri 10 Jul 2020 03:37:24 AM UTC, comment #15: 

Looks like pstoedit has changed then.  I have version 3.70 where this works (either syntax).  Maybe it it should be reported as a bug upstream.

Rik <rik5>
Group administrator
Fri 10 Jul 2020 12:09:15 AM UTC, comment #14: 

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 !

Dmitri A. Sergatskov <dasergatskov>
Thu 09 Jul 2020 10:33:44 PM UTC, comment #13: 

@Dmitri: Using your example with the intermediate file t1.pdf can you try these two commands?


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



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


The first doesn't use pipes and works according to you.

The second explicitly sets the output "file" to stdout.

At the end


diff out1.fig out2.fig


should show nothing if this approach works.

Rik <rik5>
Group administrator
Thu 09 Jul 2020 08:46:53 PM UTC, comment #12: 

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.
--


Dmitri A. Sergatskov <dasergatskov>
Thu 09 Jul 2020 08:21:43 PM UTC, comment #11: 

Again, maybe it is Octave that is doing this incorrectly.  Using 'gs -h' I get


 -sOutputFile=<file> select output file: - for stdout, |command for pipe,
                                         embed %d or %ld for page #


By default, Octave sets the output file to '-' for stdout which I suppose it then pipes to the next command.  This help text says that we should be using '|' if we want to use a pipe.


Rik <rik5>
Group administrator
Thu 09 Jul 2020 07:40:08 PM UTC, comment #10: 

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

Markus Mützel <mmuetzel>
Group administrator
Thu 09 Jul 2020 04:36:09 PM UTC, comment #9: 

what is the ghostscript version?

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Thu 09 Jul 2020 04:33:43 PM UTC, comment #8: 

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.

Markus Mützel <mmuetzel>
Group administrator
Thu 09 Jul 2020 04:33:02 PM UTC, comment #7: 

It is might be a "feature" of the newer ghostscript (9.52)
that it does not allow pipe as an output device.
If I downgrade to 9.25 the pipe redirection works,
but printing to emf still fails with

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.


(We embbed fonts to intermediate pdf).

Perhaps there is a working combo of pstoedit/ghostscript
that would work with all thses, but I cannot figure it out.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Thu 09 Jul 2020 04:17:26 PM UTC, comment #6: 

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.
--

Dmitri A. Sergatskov <dasergatskov>
Thu 09 Jul 2020 04:04:20 PM UTC, comment #5: 

Did pstoedit break pipes only on Windows?  Or is this a general problem now?

I tried pstoedit by itself on a Linux command line and got


pstoedit: version 3.70 / DLL interface 108 (built: Aug 29 2017 - release build - g++ 7.2.0 - 64-bit) : Copyright (C) 1993 - 2014 Wolfgang Glunz
No output format specified (-f option) and format could not be deduced from suffix of output file since no output file name was given
Usage: "pstoedit -f format inputfile outputfile" or run "pstoedit -help" to get a complete list available options.


This suggests it really wants an output file, rather than a pipe.  Can you test whether using the special output filename "-" works to send the output to stdout which would then make the pipe work again?

Rik <rik5>
Group administrator
Thu 09 Jul 2020 03:51:39 PM UTC, comment #4: 

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.
--

Dmitri A. Sergatskov <dasergatskov>
Mon 06 Jul 2020 10:43:36 PM UTC, comment #3: 

Since 5.2.0 is about to be deprecated, could someone verify whether the test code in the original submission runs on a Windows build of the stable branch that will become 6.1.0?

Rik <rik5>
Group administrator
Sat 04 Jul 2020 03:34:02 PM UTC, comment #2: 

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.
--

Dmitri A. Sergatskov <dasergatskov>
Sat 04 Jul 2020 12:47:42 PM UTC, comment #1: 

This is probably a duplicate of bug #57197.

Markus Mützel <mmuetzel>
Group administrator
Sat 04 Jul 2020 12:00:43 PM UTC, original submission:  

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 !

Ich selber <octavian>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #52280:  bug58702-print-emf-v2.patch added by mmuetzel (2KiB - application/octet-stream)
file #52260:  bug58702-print-emf.patch added by mmuetzel (2KiB - application/octet-stream)

 

Digest:
   bug dependencies.

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by ellocco (Posted a comment)
  • -email is unavailable- added by pantxo (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by dasergatskov (Posted a comment)
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by octavian (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 15 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-11-16 pantxo StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2021-11-16 mmuetzel StatusPatch Reviewed Ready For Test
    2021-11-14 pantxo CategoryPlotting Plotting with OpenGL
        StatusIn Progress Patch Reviewed
    2021-11-14 mmuetzel Attached File- Added bug58702-print-emf-v2.patch, #52280
        StatusNone In Progress
        Operating SystemMicrosoft Windows Any
    2021-11-14 pantxo StatusIn Progress None
        Operating SystemAny Microsoft Windows
    2021-11-14 mmuetzel StatusNone In Progress
        Operating SystemMicrosoft Windows Any
    2021-11-12 mmuetzel Attached File- Added bug58702-print-emf.patch, #52260
    2021-11-12 mmuetzel Release5.2.0 dev
    2020-07-04 mmuetzel Dependencies- Depends on bugs #57197

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code