bugGNU Octave - Bugs: bug #35259, fltk surf plots don't print...

 
 

bug #35259: fltk surf plots don't print properly

Submitter:  Ben Abbott <bpabbott>
Submitted:  Sat 07 Jan 2012 02:16:17 AM UTC
   
 
Category:  Plotting with OpenGL Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  bpabbott
Originator Name:  Ben Abbott 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

Fri 13 Jan 2012 04:20:59 PM UTC, comment #20: 

No objection to including it in 3.6.0 (I had pushed to stable for that reason).

I don't expect this change will result in any regressions, so I don't see a need for an rc2.


Ben Abbott <bpabbott>
Group Member
Fri 13 Jan 2012 03:50:59 PM UTC, comment #19: 

Ben, thanks for digging in to this problem.

I think the report can be closed now.

Unless there is some objection, I intend to include this change in the 3.6.0 release, but I don't plan to make another release candidate snapshot just for it.  Is there any objection to that?

John W. Eaton <jwe>
Group administrator
Fri 13 Jan 2012 04:09:43 AM UTC, comment #18: 

Just to second Rik's comment: nice work!

Michael

Michael Godfrey <godfrey>
Group Member
Thu 12 Jan 2012 10:40:25 PM UTC, comment #17: 

Thanks Rik!

If you look at the list of comments, I took a few wrong turns ;-)

I've pushed a changeset.

http://hg.savannah.gnu.org/hgweb/octave/rev/81ee6b12adbc

I'm not planning to replace epstool as using ghostscript or graphicsmagick to tighten the bbox modifies the eps-code and breaks compatibility with psfrag.

If there are no objections from those following along, this can be closed.

Ben Abbott <bpabbott>
Group Member
Thu 12 Jan 2012 09:29:25 PM UTC, comment #16: 

Wow.  That's some impressive root-cause analysis Ben.

Rik <rik5>
Group administrator
Thu 12 Jan 2012 07:46:59 PM UTC, comment #15: 

I've solved the problem. My notes are below.

I began by creating the simplest plot that demonstrated the problem.


graphics_toolkit fltk
close all
peaks (2)
print -depsc peaks2.eps
peaks (10)
print -depsc peaks3.eps


I used ghostscript to determine the bbox size.


$ gs -dNOPAUSE -dBATCH -sDEVICE=bbox peaks2.eps
GPL Ghostscript 9.04 (2011-08-05)
Copyright (C) 2011 Artifex Software, Inc.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Loading NimbusSanL-Regu font from /opt/local/share/ghostscript/9.04/Resource/Font/NimbusSanL-Regu... 3570136 2112862 3067472 1778701 2 done.
%%BoundingBox: 29 48 539 418
%%HiResBoundingBox: 29.789999 48.239999 538.235984 417.599987

$ gs -dNOPAUSE -dBATCH -sDEVICE=bbox peaks3.eps
GPL Ghostscript 9.04 (2011-08-05)
Copyright (C) 2011 Artifex Software, Inc.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Loading NimbusSanL-Regu font from /opt/local/share/ghostscript/9.04/Resource/Font/NimbusSanL-Regu... 3570136 2112862 3067472 1778701 2 done.
%%BoundingBox: 0 0 150977 150977
%%HiResBoundingBox: 0.000000 0.000000 150976.921393 150976.921393


peaks2.eps is ok, but peaks3.eps is not (bbox is too large).

Next I experimented with the eps-files to see if I could isolate the problem. With the diff below applield to peaks3.eps, the bbox is determined correctly by ghostscript.


$ diff peaks3.eps foobar.eps
226,227d225
< 394.988 121.261 0 0.325397 1 389.609 121.255 0 0.325397 1 175.915 158.918 0 0.325397 1 ST
< 171.788 160.599 0 0.325397 1 394.988 121.261 0 0.325397 1 175.915 158.918 0 0.325397 1 ST
246d243
< 74.88 210.239 0 0.198413 1 138.456 248.429 0 0.198413 1 140.712 247.392 0 0.198413 1 ST
331d327
< 189.606 279.155 0 0.198413 1 201.172 286.103 0 0.198413 1 193.319 281.075 0 0.198413 1 ST
348,350d343
< 138.456 248.429 0 0.198413 1 189.606 279.155 0 0.198413 1 193.319 281.075 0 0.198413 1 ST
< 147.992 252.053 0 0.198413 1 140.213 247.622 0 0.198413 1 138.456 248.429 0 0.198413 1 ST
< 193.319 281.075 0 0.198413 1 147.992 252.053 0 0.198413 1 138.456 248.429 0 0.198413 1 ST
568d560
< 389.609 121.255 0 0.325397 1 268.695 121.121 0 0.325397 1 175.915 158.918 0 0.325397 1 ST


The ghostscript result, for foobar.eps, is below. It is approximately the same as for peaks2.eps.


$ gs -dNOPAUSE -dBATCH -sDEVICE=bbox foobar.eps
GPL Ghostscript 9.04 (2011-08-05)
Copyright (C) 2011 Artifex Software, Inc.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Loading NimbusSanL-Regu font from /opt/local/share/ghostscript/9.04/Resource/Font/NimbusSanL-Regu... 3570136 2112862 3067472 1778701 2 done.
%%BoundingBox: 43 48 539 418
%%HiResBoundingBox: 43.793999 48.239999 538.235984 417.600058
-verbatim

The differnece in the LL margin is due the change in yticklabels. The longest yticklabel in peaks2.eps is "-2e-05" and that in foobar.eps is "-0.4". Those are ababout 35 and 21 points long, respectively (I measured them). Thus, the peaks2.eps should loose about 14 points. 43 - 14 = 29 points. Which is what the bbox from ghostscript for peaks2.eps gave.

The command "ST" is defined below

+verbatim+
tryPS3shading
{ /shfill where
  { /ST { STshfill } BD }
  { /ST { STnoshfill } BD }
  ifelse }
{ /ST { STnoshfill } BD }
ifelse
end
-verbatiim-

and tryPS3shading is defined true.

+verbatim+
/tryPS3shading true def % set to false to force subdivision
-verbatiim-

Therefore, we have the equivalent of

+verbatim+
/ST { STshfill } BD
-verbatiim-

If I change the definition of ST to STnoshfill

+verbatim+
/ST { STnoshfill } BD
-verbatiim-

or change the state of tryPS3shading to false

+verbatim+
/tryPS3shading true def % set to false to force subdivision
-verbatiim-

I get the correct result.

+verbatim+
$ gs -dNOPAUSE -dBATCH -sDEVICE=bbox peaks3.eps
GPL Ghostscript 9.04 (2011-08-05)
Copyright (C) 2011 Artifex Software, Inc.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Loading NimbusSanL-Regu font from /opt/local/share/ghostscript/9.04/Resource/Font/NimbusSanL-Regu... 3570136 2112862 3067472 1778445 2 done.
%%BoundingBox: 43 48 539 418
%%HiResBoundingBox: 43.793999 48.239999 538.235984 417.600058


If I infer corretly, the "tryPS3shading" refers to support for shading (GLSL in OpenGL, HLSL by MSFT & Nvidia). PS 3.0 has "Shader Model 3".

I looked over the history of ghostscript9, but was unable to determine if PS 3.0's Shader Model 3 is supposed to be supported or not.

  http://ghostscript.com/doc/current/History9.htm

Looking at the gl2ps manual, I see the note below.


If you plan to convert PostScript files into PDF files,
you may need to disable the use of the Level 3 PostScript
shfill operator, i.e., add GL2PS_NO_PS3_SHADING to the
list of options passed to gl2psBeginPage.


Using the diff below solves the problem for me.


$ hg diff
diff --git a/src/gl2ps-renderer.cc b/src/gl2ps-renderer.cc
--- a/src/gl2ps-renderer.cc
+++ b/src/gl2ps-renderer.cc
@@ -79,7 +79,8 @@
                           gl2ps_term, GL2PS_BSP_SORT,
                           (GL2PS_SILENT | GL2PS_SIMPLE_LINE_OFFSET
                            | GL2PS_NO_BLENDING | GL2PS_OCCLUSION_CULL
-                           | GL2PS_BEST_ROOT | gl2ps_text),
+                           | GL2PS_BEST_ROOT | gl2ps_text
+                           | GL2PS_NO_PS3_SHADING),
                           GL_RGBA, 0, NULL, 0, 0, 0,
                           buffsize, fp, "" );


I'll push a changeset later.

Ben Abbott <bpabbott>
Group Member
Wed 11 Jan 2012 11:26:20 PM UTC, comment #14: 

I have not yet determined why the gl2ps eps-files are violating the operand stack count. However, I did confirm that adding by saving the initial state and then restoring it after the eps-file code is run, the problem goes away.

At the top of the eps-file I placed,

/init_state_before_gl2ps save def % save initial state

And at the bottom.

init_state_before_gl2ps def % restore initial state


Then I ran,


epstool --test-eps example.eps


and obtained


"gs"  -dNOEPS -dNOPAUSE -dBATCH -dNODISPLAY  "/tmp/gsviewe6S7SC"
GPL Ghostscript 9.04 (2011-08-05)
Copyright (C) 2011 Artifex Software, Inc.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Loading NimbusSanL-Regu font from /opt/local/share/ghostscript/9.04/Resource/Font/NimbusSanL-Regu... 3549856 2099512 2646152 1352409 3 done.

EPSWARN PASS

"gs"  -dNOPAUSE -dBATCH -sDEVICE=bbox   -c "<</PageSize [9400 9400] /PageOffset [3000 3000]>> setpagedevice" -f "/tmp/gsviewkhfqyE"
GPL Ghostscript 9.04 (2011-08-05)
Copyright (C) 2011 Artifex Software, Inc.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Loading NimbusSanL-Regu font from /opt/local/share/ghostscript/9.04/Resource/Font/NimbusSanL-Regu... 3570136 2106567 4334464 3030451 3 done.
%%BoundingBox: 3042 3043 3510 3422
%%HiResBoundingBox: 3042.071907 3043.655907 3509.531893 3421.007896

File has   %%BoundingBox: 0 0 576 450
Correct is %%BoundingBox: 42 43 510 422
PostScript appears well behaved.
File claims to be EPS.
PASS: File appears to be well behaved EPS.
OK


This isn't a proper fix, but it does give an indication that the gl2ps eps-file is either leaving an operand on the stack or is eating one.

Ben Abbott <bpabbott>
Group Member
Wed 11 Jan 2012 02:36:59 AM UTC, comment #13: 

I took a look at "gm convert". It did filter out the problem with the gl2ps eps-file.

Unfortunately it severely degrades the quality of the image.

Looks like we'll need to use ghostscript, or fix the bug in gl2ps.

When I have the time, I'll try to determine what it is about the gl2ps' eps-file that isn't compliant with the eps-standard.


Ben Abbott <bpabbott>
Group Member
Mon 09 Jan 2012 03:38:39 PM UTC, comment #12: 

Ben,

Two points:
1. Have you looked at "convert" which is
part of ImageMagick?  I am not sure it would
be useful, but it claims to do a lot of conversions,
and ImageMagick seems to be a widely available
package.

2. epstool is not mentioned anywhere in the current Manual,
specifically not in Appendix G where all the required
dependencies are listed.

Michael Godfrey <godfrey>
Group Member
Mon 09 Jan 2012 01:29:28 PM UTC, comment #11: 

The epstool utility is also being used to add the tiff preview.

I'll leave the epstool as it is, but use gs to handle the -tight option.

Ben Abbott <bpabbott>
Group Member
Mon 09 Jan 2012 02:29:43 AM UTC, comment #10: 

Michael,

I work on a changeset that replaces epstool with gs.

Currently Octave produces a tight bbox with


epstool --quiet --copy --bbox /var/tmp/oct-lyuJ05.eps 'test.eps'


I'll replace this with something to the effect of


gs -sDEVICE=epswrite -sOutputFile='test.eps' -dBATCH -dNOPAUSE -q -


If I recall correctly epstool had some problem with pipes. If a tight bbox is the only reason we needed epstool, then I'm happy to avoid it.

Ben Abbott <bpabbott>
Group Member
Mon 09 Jan 2012 02:15:19 AM UTC, comment #9: 

I forgot to mention the results of "epstool --test-eps foobar.eps"


$ epstool --test-eps foobar.eps
"gs"  -dNOEPS -dNOPAUSE -dBATCH -dNODISPLAY  "/tmp/gsview6tWvVQ"
GPL Ghostscript 9.04 (2011-08-05)
Copyright (C) 2011 Artifex Software, Inc.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.

EPSWARN PASS

"gs"  -dNOPAUSE -dBATCH -sDEVICE=bbox   -c "<</PageSize [9400 9400] /PageOffset [3000 3000]>> setpagedevice" -f "/tmp/gsviewBuLJ3K"
GPL Ghostscript 9.04 (2011-08-05)
Copyright (C) 2011 Artifex Software, Inc.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
%%BoundingBox: 3046 3048 3539 3418
%%HiResBoundingBox: 3046.800001 3048.191907 3538.205892 3417.841232

File has   %%BoundingBox: 46 48 539 418
Correct is %%BoundingBox: 46 48 539 418
PostScript appears well behaved.
File claims to be EPS.
PASS: File appears to be well behaved EPS.
OK


By default ML produces the tight version. Maybe Mathworks decided it best to filter the generated eps code through gs to be sure result is compliant?

Ben Abbott <bpabbott>
Group Member
Mon 09 Jan 2012 02:13:16 AM UTC, comment #8: 

Since this bug depends on epstool, can I ask: is
epstool appropriately necessary for Octave plotting?
It appears that it is not in standard distributions.
In fact, I think it is the only non-standrard package
used by Octave in Fedora systems.  Could what it does be
done by ghostscript?

If this question has already been asked, just say what the
answer was.

Thanks,
Nichael

Michael Godfrey <godfrey>
Group Member
Mon 09 Jan 2012 01:54:50 AM UTC, comment #7: 

I found a work around. First I produced a normal eps-file


graphics_toolkit fltk
close all
peaks (10)
print -depsc test.eps


Then I passed the result thru ghostscript.


gs -sDEVICE=epswrite -sOutputFile=foobar.eps -dBATCH test.eps


The resulting foobar.eps has a tight bbox. I don't see where this is documented but did find it mentioned in the bug report below.

http://bugs.ghostscript.com/show_bug.cgi?id=689629

I'll put this on my list of to-do's.

Ben Abbott <bpabbott>
Group Member
Mon 09 Jan 2012 01:26:45 AM UTC, comment #6: 

Doug,

I'm running gs 9.04 and epstool 3.08 on MacOS X.

My Ubuntu 10.04 has gs 8.71 and epstool 3.08. I see same result as you.

This seems to suggest the bug is with ghostscript 9.04.

I've been trying to figure out how to build and install an older version of ghostscript using macports, but haven't figured it out yet.

Ben Abbott <bpabbott>
Group Member
Mon 09 Jan 2012 12:59:43 AM UTC, comment #5: 

My epstool version is


$ epstool --version
epstool 3.08 2005-06-06


I tried the commands below.


close all
graphics_toolkit fltk
peaks (1)
print -depsc -tight test.eps


They produced an eps-file with the header below.


%!PS-Adobe-3.0 EPSF-3.0
%%BoundingBox: -3000 -3000 6400 6400
%%HiResBoundingBox: -2999.999 -2999.999 6399.996 6399.996
%%Title: glps_renderer figure
%%Creator: GL2PS 1.3.6, (C) 1999-2011 C. Geuzaine
%%For: Octave
%%CreationDate: Sun Jan  8 19:35:25 2012
%%LanguageLevel: 3
%%DocumentData: Clean7Bit
%%Pages: 1
%%EndComments
%%BeginProlog


Using gnuplot, I get the expected result.


%!PS-Adobe-2.0 EPSF-2.0
%%BoundingBox: 98 91 565 444
%%HiResBoundingBox: 98.196 91.122 564.261 443.971
%%Title: /var/tmp/oct-OlOPsz.eps
%%Creator: gnuplot 4.4 patchlevel 4
%%CreationDate: Sun Jan  8 19:37:48 2012
%%DocumentFonts: (atend)
%%EndComments
%%BeginProlog


Rik, the "print -tight" option isn't equivalent to "axis tight". It shouldn't change the axis ticks. Instead it tightens the bounding box around the figues children (which may include one or more axes). Even so, your suggestion that Octave handle the "-tight" can work for the opengl backends. We'd have to modify the position properties of each axis to for the looseinset on edges of the figure's axes to zero. Kostas was good at such things, but its a weakness of mine. I'll give this some more thought. Perhaps there's another way.


Ben Abbott <bpabbott>
Group Member
Mon 09 Jan 2012 12:27:50 AM UTC, comment #4: 

Interestingly, running Kubuntu 10.04 with the same versions of Ghostscript and epstool I get a different result.  I did a diff of Doug's test.eps and the one generated on my machine and they are different.  In particular, the bounding box specification is different.  Maybe there are differences due to installed fonts?  gl2ps is the same version between both machines as well.

Rik <rik5>
Group administrator
Sun 08 Jan 2012 11:54:48 PM UTC, comment #3: 

On Ubuntu 10.04 I get:


doug@doug-desktop:~$ epstool --test-eps test.eps
"gs"  -dNOEPS -dNOPAUSE -dBATCH -dNODISPLAY  "/tmp/gsview9Yc9ME"
GPL Ghostscript 8.71 (2010-02-10)
Copyright (C) 2010 Artifex Software, Inc.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Loading NimbusSanL-Regu font from /var/lib/defoma/gs.d/dirs/fonts/n019003l.pfb... 2325924 992949 2093988 789097 2 done.
EPSWARN FAIL: EPS file altered operand stack count

EPSWARN FAIL

"gs"  -dNOPAUSE -dBATCH -sDEVICE=bbox   -c "<</PageSize [9400 9400] /PageOffset [3000 3000]>> setpagedevice" -f "/tmp/gsviewYqGuGr"
GPL Ghostscript 8.71 (2010-02-10)
Copyright (C) 2010 Artifex Software, Inc.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Loading NimbusSanL-Regu font from /var/lib/defoma/gs.d/dirs/fonts/n019003l.pfb... 2325996 992779 4027292 2727351 2 done.
%%BoundingBox: 3047 3062 3523 3421
%%HiResBoundingBox: 3047.831907 3062.951907 3522.779892 3420.727067

File has   %%BoundingBox: 47 62 523 421
Correct is %%BoundingBox: 47 62 523 421
File used PostScript operators that are prohibited in an EPS file.
File claims to be EPS.
FAIL: File does not comply with EPS specification.
Failed
doug@doug-desktop:~$ epstool --help
epstool 3.08 2005-06-06
Copyright 1995-2005 Ghostgum Software Pty Ltd
Usage: epstool command [options] inputfile outputfile

You can see the file  here:

http://ubuntuone.com/37jmrGkIYLnYbxYjyBvyYQ


As you can see I am using epstool 3.08
and the resulting picture look normal.
I hope this helps
Doug

Doug Stewart <dastew>
Sun 08 Jan 2012 10:10:19 PM UTC, comment #2: 

This problem exists for me on Kubuntu 10.04 so I don't think it is Mac specific.  I don't have epstool installed and when I run the set of commands I get:


print -depsc -tight test.eps
warning: print.m: epstool binary is not available.
Some output formats are not available.
error: print.m: 'epstool' not found in PATH
error: called from:
error:   /home/rik/wip/Projects_Mine/octave-doc/scripts/plot/print.m at line 518, column 7
error: evaluating argument list element number 1
error:   /home/rik/wip/Projects_Mine/octave-doc/scripts/plot/private/__fltk_print__.m at line 46, column 10
error:   /home/rik/wip/Projects_Mine/octave-doc/scripts/plot/print.m at line 382, column 12


If I run without the '-tight' option the command works and generates a correctly sized eps image.

If I install epstool, an image is created but it is super small as in the original bug report.  If I run a diff on the two different eps files I get


< %%BoundingBox: 0 0 576 452
> %%BoundingBox: -3000 -3000 6400 6400
> %%HiResBoundingBox: -2999.999 -2999.999 6399.996 6399.996


The problem does not seem to be Octave, but rather epstool which is updating the bounding box to some huge value.  If I manually edit the eps file and restore the original bounding box then the figure is normal again.

It seems that either epstool is broken or we are not calling it correctly.  As a work around, could we implement an unwind_protect block to have the 'tight' done by Octave rather than epstool?  I'm thinking of something like this.


unwind_protect
  old_axis = axis ();
  axis ("tight");
  print ...options...;
unwind_protect_cleanup
  axis (old_axis);
end_unwind_protect


It also seems that the generated eps is not correct.  If I run epstool with the --test-eps option I get the following.


epstool --test-eps test.eps

"gs"  -dNOPAUSE -dBATCH -sDEVICE=bbox   -c "<</PageSize [9400 9400] /PageOffset [3000 3000]>> setpagedevice" -f "/tmp/gsviewxZhWIh"
GPL Ghostscript 8.71 (2010-02-10)
Copyright (C) 2010 Artifex Software, Inc.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Loading NimbusSanL-Regu font from /var/lib/defoma/gs.d/dirs/fonts/n019003l.pfb... 3567728 1816507 4294096 2967457 2 done.
%%BoundingBox: 0 0 9400 9400
%%HiResBoundingBox: 0.000000 0.000000 9399.995713 9399.995713

File has   %%BoundingBox: 0 0 576 452
Correct is %%BoundingBox: -3000 -3000 6400 6400
File bounding box needs to be larger
File used PostScript operators that are prohibited in an EPS file.
File claims to be EPS.
FAIL: File does not comply with EPS specification.
Failed


Rik <rik5>
Group administrator
Sat 07 Jan 2012 05:54:23 PM UTC, comment #1: 
Ben Abbott <bpabbott>
Group Member
Sat 07 Jan 2012 02:16:17 AM UTC, original submission:  


graphics_tollkit fltk
close all
peaks (10)
print -depsc -tight test.eps


The resulting  eps is large, but but surf plot is tiny. I've attached the result.

Ben Abbott <bpabbott>
Group Member

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #24755:  test.eps.zip added by bpabbott (24KiB - application/zip)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by godfrey (Posted a comment)
  • -email is unavailable- added by dastew (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by bpabbott (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 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2012-01-13 bpabbott Open/ClosedOpen Closed
    2012-01-12 bpabbott StatusIn Progress Fixed
        Assigned toNone bpabbott
    2012-01-12 bpabbott StatusConfirmed In Progress
    2012-01-08 rik5 StatusNone Confirmed
    2012-01-08 rik5 Operating SystemMac OS Any
    2012-01-07 bpabbott Attached File- Added test.eps.zip, #24755

    Back to the top

    Powered by Savane 3.13-cf05.
    Corresponding source code