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

 
 

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

Submitted by:  Ich selber <octavian>
Submitted on:  Sat 04 Jul 2020 12:00:43 PM UTC  
 
Category:  Plotting Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Regression
Status:  None Assigned to:  None
Originator Name:  Octavian Open/Closed:  Open
Release:  5.2.0 Operating System:  Microsoft Windows

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

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>
Project 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>
Project 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>
Project 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>
Project 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>
Project Member
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>
Project Member
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>
Project 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>
Project 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>
Project Member
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:
   

No files currently attached

 

Digest:
   bug dependencies.

Items that depend on this one: None found

 

Carbon-Copy List
  • -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)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

     

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-07-04 mmuetzel Dependencies- => Depends on bugs #57197

    Back to the top


    Powered by Savane 3.5