bugGNU Octave - Bugs: bug #64164, Wrong eps boundingbox

 
 

bug #64164: Wrong eps boundingbox

Submitter:  Leonardo <pocker>
Submitted:  Mon 08 May 2023 11:45:20 AM UTC
   
 
Category:  Plotting with OpenGL Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Confirmed Assigned to:  None
Originator Name:  Open/Closed:  * Open
Release:  * 8.2.0 Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Thu 11 May 2023 08:10:15 PM UTC, comment #5: 

I'd like to suggest a simple workaround:

instead of converting the pdf to eps, the toolchain could convert  pdf to ps and then convert it to eps using


ps2eps -f -q test.ps


Now the bbox is


%%BoundingBox: 38 18 385 294


I may be wrong, but ps2eps seems to be a Perl script that calls gs during its execution.

So, may be possible to dig into it (and this is beyond me) to catch how the boundingbox is calculated/updated/corrected to create the eps file.

I guess that this is the best I can do.

 Leonardo <pocker>
Thu 11 May 2023 05:43:33 PM UTC, comment #4: 

Hi.

I tried to do a step-by-step in the svgconvert toolchain.

1) print to SVG with

plot(1:10)
print -dsvg test.svg


2) use the

octave-svgconvert

to convert test.svg to test.pdf

3) use gs to convert test.pdf to test.eps
Result:

%%BoundingBox: 0 0 419 314


I'm still trying to figure out how to convert test.pdf to test.eps with correct BoundingBox which is the last command of the svgconvert toolchain

Well, IIUC, this is how the "print -depsc2 test.eps" is performed under the hood.

 Leonardo <pocker>
Tue 09 May 2023 10:16:38 AM UTC, comment #3: 

Changed "ps2write" to "eps2write". Same result.


>> print -depsc2 -debug test.eps
svgconvert command: '/usr/local/libexec/octave/8.2.0/exec/x86_64-pc-linux-gnu/octave-svgconvert - %s 96.13 "/usr/local/share/octave/8.2.0/fonts/FreeSans.otf" 1 "%s"'
Ghostscript command: '/usr/bin/gs -dQUIET -dNOPAUSE -dBATCH -dSAFER -dAutoRotatePages=/None -sDEVICE=eps2write -dLanguageLevel=2 -dEPSCrop -sOutputFile="test.eps" /tmp/oct-NLtNPl'
opengl-pipeline: '/usr/local/libexec/octave/8.2.0/exec/x86_64-pc-linux-gnu/octave-svgconvert - pdf 96.13 "/usr/local/share/octave/8.2.0/fonts/FreeSans.otf" 1 "/tmp/oct-NLtNPl" ; /usr/bin/gs -dQUIET -dNOPAUSE-dBATCH -dSAFER -dAutoRotatePages=/None -sDEVICE=eps2write -dLanguageLevel=2 -dEPSCrop -sOutputFile="test.eps" /tmp/oct-NLtNPl'


The header of test.eps:


%!PS-Adobe-3.0 EPSF-3.0
%%Invocation: path/gs -dQUIET -dNOPAUSE -dBATCH -dSAFER -dAutoRotatePages=/None -sDEVICE=eps2write -dLanguageLevel=2 -dEPSCrop -sOutputFile=? ?
%%BoundingBox: 0 0 419 314
%%HiResBoundingBox: 0.00 0.00 419.00 314.00
%%Creator: GPL Ghostscript 9550 (eps2write)
%%LanguageLevel: 2
%%CreationDate: D:20230509070441-03'00'
%%Pages: 1
%%EndComments
%%BeginProlog


Odd thing is, if I print to PDF and then convert to eps, things are nice:


>> print -dpdf -debug test.pdf
svgconvert command: '/usr/local/libexec/octave/8.2.0/exec/x86_64-pc-linux-gnu/octave-svgconvert - %s 96.13 "/usr/local/share/octave/8.2.0/fonts/FreeSans.otf" 1 "%s"'
---- begin /tmp/oct-HF0kyJ.ps ----
%!PS-Adobe-3.0
<< /Margins [0 0] /.HWMargins [0 0 0 0] /PageOffset [96 238] >> setpagedevice
%%EOF
----- end /tmp/oct-HF0kyJ.ps -----
Ghostscript command: '/usr/bin/gs -dQUIET -dNOPAUSE -dBATCH -dSAFER -dAutoRotatePages=/None -sDEVICE=pdfwrite -dLanguageLevel=2 -dEmbedAllFonts=true -dOptimize=true -dEPSCrop -sPAPERSIZE=letter -dFIXEDMEDIA -sOutputFile="test.pdf" "/tmp/oct-HF0kyJ.ps" /tmp/oct-hepepU'
opengl-pipeline: '/usr/local/libexec/octave/8.2.0/exec/x86_64-pc-linux-gnu/octave-svgconvert - pdf 96.13 "/usr/local/share/octave/8.2.0/fonts/FreeSans.otf" 1 "/tmp/oct-hepepU" ; /usr/bin/gs -dQUIET -dNOPAUSE-dBATCH -dSAFER -dAutoRotatePages=/None -sDEVICE=pdfwrite -dLanguageLevel=2 -dEmbedAllFonts=true -dOptimize=true -dEPSCrop -sPAPERSIZE=letter -dFIXEDMEDIA -sOutputFile="test.pdf" "/tmp/oct-HF0kyJ.ps" /tmp/oct-hepepU ; rm "/tmp/oct-HF0kyJ.ps"'


Now, convert it to eps using


gs -q -dNOCACHE -dNOPAUSE -dBATCH -dSAFER -sDEVICE=eps2write -sOutputFile=output.eps test.pdf


The header of output.eps is


%!PS-Adobe-3.0 EPSF-3.0
%%Invocation: gs -q -dNOCACHE -dNOPAUSE -dBATCH -dSAFER -sDEVICE=eps2write -sOutputFile=? ?
%%BoundingBox: 96 237 516 552
%%HiResBoundingBox: 96.00 237.70 515.20 552.00
%%Creator: GPL Ghostscript 9550 (eps2write)
%%LanguageLevel: 2
%%CreationDate: D:20230509071226-03'00'
%%Pages: 1
%%EndComments
%%BeginProlog



 Leonardo <pocker>
Mon 08 May 2023 05:15:10 PM UTC, comment #2: 

Confirmed here.

At least with the tools I have, the headers of these files look slightly differently.

-svgvonvert:

%!PS-Adobe-3.0
%%Invocation: path/gs.exe -dQUIET -dNOPAUSE -dBATCH -dSAFER -dAutoRotatePages=/None -sDEVICE=ps2write -dLanguageLevel=2 -dEmbedAllFonts=true -dEPSCrop -sOutputFile=? ?
%%BoundingBox: 0 0 248 184
%%HiResBoundingBox: 0 0 248.00 184.00
%%Creator: GPL Ghostscript 950 (ps2write)
%%LanguageLevel: 2


-nosvgconvert:

%!PS-Adobe-3.0 EPSF-3.0
%%BoundingBox: 1 2 80 77
%%HiResBoundingBox: 1.608 2.598 79.764 76.812
%%Invocation: path/gs.exe -dQUIET -dNOPAUSE -dBATCH -dSAFER -dAutoRotatePages=/None -sDEVICE=eps2write -sOutputFile=? - ?
%%Creator: GPL Ghostscript 950 (eps2write)
%%LanguageLevel: 2


The first line is different.
For the file that "works", the line with BoundingBox is the first comment line.
IIUC, the "good" file was created with `eps2write`, the "bad" file was created with `ps2write`.

I don't know whether that makes any difference.

Should the following `if (do_eps)` block select `"eps2write"` instead of `"ps2write"`?
https://hg.savannah.gnu.org/hgweb/octave/file/4e30fd192118/scripts/plot/util/private/__print_parse_opts__.m#l812

  if (do_eps)
    aliases.eps   = "ps2write";
    aliases.eps2  = "ps2write";
    aliases.epsc  = "ps2write";
    aliases.epsc2 = "ps2write";
  endif



 Markus Mützel <mmuetzel>
Group administrator
Mon 08 May 2023 04:24:21 PM UTC, comment #1: 

Did another test, now with -nosvgconvert


subplot('position',[0.05 0.1 0.25 0.3])
plot(1:10)
print -depsc -nosvgconvert example2.eps


The epstool now claims the file is OK:


File has   %%BoundingBox: 4 15 131 129
Correct is %%BoundingBox: 4 15 131 129
PostScript appears well behaved.
File claims to be EPS.
PASS: File appears to be well behaved EPS.
OK


Besides, without the '-nosvgconvert', the quality of the ps/eps is not very good.

Anyway, this "bug" may help other people also.

Kind regards.

(file #54712)

 Leonardo <pocker>
Mon 08 May 2023 11:45:20 AM UTC, original submission:  

Hi.

Probably this is not a bug of Octave, but I would like to have another opinion.

I'm using Octave 8.2.0 (compiled from source) and I realized that when I print to eps, the BoundingBox is not correct no matter if I use '-tight' or '-loose' options.

Attached is the eps generated with:


subplot('position',[0.05 0.1 0.25 0.3])
plot(1:10)
print -depsc example.eps


The BoundingBox is 0 0 418 314.

If I run the command


epstool --test-eps example.eps


it says that


File is not EPS.
FAIL: File does not comply with EPS specification.
Failed


And with this tool there is no way to get the correct bbox.

I found two workarounds:

1)

Use the gs command to get the correct bbox


gs -dSAFER -dNOPAUSE -dBATCH -sDEVICE=bbox example.eps


which will give

BoundingBox: 4 15 131 129

and here one can edit the eps and change manually.

2)

Print to ps and then convert using the ps2eps command

My best guess is that something changed in the GhostScript and the epstool was not updated.

Any thought?

 Leonardo <pocker>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #54712:  example2.eps added by pocker (7KiB - image/x-eps)
file #54711:  example.eps added by pocker (168KiB - image/x-eps)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by pocker (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 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2023-05-08 mmuetzel StatusNone Confirmed
        Operating SystemGNU/Linux Any
    2023-05-08 pocker Attached File- Added example2.eps, #54712
    2023-05-08 pocker Attached File- Added example.eps, #54711

    Back to the top

    Copyright © 2024 Free Software Foundation, Inc.
    Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
    The Levitating, Meditating, Flute-playing Gnu logo is a GNU GPL'ed image provided by the Nevrax Design Team.
    Page source code

    Powered by Savane 3.14-f13d.
    Corresponding source code