[Octave-bug-tracker] [bug #35259] fltk surf plots don't print properly

[Ben Abbott]

Update of bug #35259 (project octave):

                  Status:               Confirmed => In Progress            

    _______________________________________________________

Follow-up 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


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

and tryPS3shading is defined true.


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

Therefore, we have the equivalent of


/ST { STshfill } BD
-verbatiim-

If I change the definition of ST to STnoshfill


/ST { STnoshfill } BD
-verbatiim-

or change the state of tryPS3shading to false


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

I get the correct result.


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


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?35259>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/