gnuplot-beta

Splot map and gd.trm bugs (long)

[<mw...@us...>]

I'm using the CVS head.

I noticed a very weird problem when using 'set view map' in conjunction
with 'splot' (aka. splot map).  The symptom was noticed when I created
some PNG files using TTF fonts.  The x & y tics and labels looked
fuzzy.  I initially thought the problem was is gd.trm.  However, I
realized that the tics and labels were actually being drawn twice.
Then I realized that the grid was not being drawn in the back as
specified.  This was all very confusing.

I have done some digging through the code and found a couple of
issues.  First, gd.trm has two differing variables for storing
character size information: term->[vh]_char and png_state.char[wh].
These are often set to each other.  However, when finding approximate
TTF font info the png_state.char[wh] variables were not being set.  A
quick fix is to always set png_state.char[wh] when the TTF font info
is determined.  So when the title font is different or invalid, the
character size data is wrong when the axis text is drawn.  This will
removed the fuzziness from the PNG plot.

I'm thinking that gd.trm should only have one variable that holds the
character size info and that should probably be term->[vh]_char.

It does nothing to address why the tics and labels are being drawn
twice.  So, I began comparing the 2D plotting stuff to the 3D stuff.

I found that the drawing order for 2D and 3D were different.  It
appears that the layer settings are not working properly in the 3D
code.  I discovered that draw_3d_graphbox is called repeatedly and
that is why the tics and axis labels are drawn twice.  The x & y tics
and labels are drawn every time draw_3d_graphbox is called.

I suggest that draw_3d_graphbox be broken up into three routines:
place_grid3d, plot_border3d, and place_axis_labels3d.  This would
allow finer control over drawing each part on the proper layer.  I'm
willing to tackle the break up of the routine if its agreed upon.

The other thing I noticed is that the pre-processor token
USE_GRID_LAYERS is set in graph3d.c and is not used as a configuration
option anywhere.  Can it be eliminated?

Below is the a script that illustrates the problem using some
exaggerated settings.  You will notice that the grid is supposed to be
in the back and the border in the front.  However, the result has the
grid in front over the border and the data points in the 3D splot map
but not the 2D plot.  Another odd thing is that the colorbox shows up
on the 2D plot when its not needed.

Mike Sutton

set term x11 persist
set style line 98 lt 1 lw 1 lc rgb 'magenta'
set style line 99 lt -1 lw 3 lc rgb 'cyan'
set grid back ls 98
unset key
set xr [-60:60]
set yr [-60:60]
set xlabel "MY Xlabel"
set ylabel "MY Ylabel"
set cblabel "MY CB"
set border front ls 99
set pm3d
set view map
png = 0
if (png > 0) set term png  giant truecolor butt nocrop size 1280,1024;\
  set term png font "luxirr,8"; \
  set out 'splot-gd.png'
set title "3D SPLOT MAP" font "luxirr,40"
#set title font "luxirrdd,40"
if (png >0) set term png font "luxirr,16"

splot "mike2.dat" w p pt 5 ps 4 lc pal

if (png < 1) set term x11 2
if (png >0) set out 'plot-gd.png'
set title "2D PLOT"

plot 'mike2.dat' w p pt 5 ps 4


-- data 
0  0   44
0  10  -2 
-30. 20 8
50 30 -5
-33 -44 10

Re: Splot map and gd.trm bugs (long)

[Ethan A M. <merritt@u.washington.edu>]

On Saturday 16 December 2006 14:29, Mike Sutton wrote:
> 
> I noticed a very weird problem when using 'set view map' in conjunction
> with 'splot' (aka. splot map).  The symptom was noticed when I created
> some PNG files using TTF fonts.  The x & y tics and labels looked
> fuzzy.  I initially thought the problem was is gd.trm.  However, I
> realized that the tics and labels were actually being drawn twice.
> Then I realized that the grid was not being drawn in the back as
> specified.  This was all very confusing.

You have identified 2 or maybe 3 separate bugs here.

1) The axis/grid/border lines in "set view map" should be handled as
   they are for 2D plots, not 3D plots

2) For some sequence of commands (illustrated by your script) the
   selection of the colorbox is not reset

3? (gd.trm only) If the font for the plot title is not found, then
   initialization of the default font for the rest of the plot may
   be corrupted. I thought this bug had been fixed, but perhaps it
   has resurfaced.

> I have done some digging through the code and found a couple of
> issues.  First, gd.trm has two differing variables for storing
> character size information: term->[vh]_char and png_state.char[wh].
> These are often set to each other.  However, when finding approximate
> TTF font info the png_state.char[wh] variables were not being set.  A
> quick fix is to always set png_state.char[wh] when the TTF font info
> is determined.

Did you find a specific place where this is not already being done?

Although the situation is not ideal, the two sets of variables are not
quite the same.  The term->[vh]_char values are exported by each terminal
to the core routines so that they can estimate the space that will be
required for various labels, titles and plot elements.
The true values of the ttf font properties used for any particular 
element are not known at that point, only those of the default font.

The png_state.* variables are used only internally, and should correspond
to the _current_ values (i.e. those of the most recent font used). But
these will change every time an explicit font or font size is encountered.
You wouldn't in general want to export these via term->[vh]_char because
there is no particular expectation that they will be used in the future
for subsequent plot elements.

> So when the title font is different or invalid, the 
> character size data is wrong when the axis text is drawn.  This will
> removed the fuzziness from the PNG plot.

I'm not following you here.  What does any of this have to do
with "fuzziness"?

> I found that the drawing order for 2D and 3D were different.  It
> appears that the layer settings are not working properly in the 3D
> code.  I discovered that draw_3d_graphbox is called repeatedly and
> that is why the tics and axis labels are drawn twice.  The x & y tics
> and labels are drawn every time draw_3d_graphbox is called.

There may be bug, but at least let me explain the logic as I understand
it.  The 3D code unfortunately does not do true depth-ordering for all
plot elements.  Instead it provides various partial solutions. For
lines and grid surfaces (and more recently points and labels) there is 
"set hidden3d".  For pm3d surfaces there is "set pm3d depthorder".
The axes, grid, and border lines are not handled by either of these.
Instead the code tries to draw them in three passes, back/middle/front,
in the hope that this coarse depth-ordering is good enough for most
plots. 

> I suggest that draw_3d_graphbox be broken up into three routines:
> place_grid3d, plot_border3d, and place_axis_labels3d.  This would
> allow finer control over drawing each part on the proper layer.  I'm
> willing to tackle the break up of the routine if its agreed upon.

I don't see how that would help at all.  I think the true fix is to
fold the axes, border, and grid into the general depth-sorting that
is done by hidden3d.

However, that whole logic and procedure was intended for true 3D plots.
It's relevance to "set view map" is dubious.  Large chunks of the
"set view map" code are shared with 2D, and probably more should be.
It is conceivable that a bug exists currently such that some element
is actually drawn twice, once by the 2D code and again by the 3D code.
If you have found such an example, we should definitely quash that bug.

> The other thing I noticed is that the pre-processor token
> USE_GRID_LAYERS is set in graph3d.c and is not used as a configuration
> option anywhere.  Can it be eliminated?

If you mean eliminate the conditional test and just use the new code
always, then I think yes.  I'm figuring that once 4.2 is officially
released we can have a grand round of removing dead code and conditional
tests for features that are no longer marked EXPERIMENTAL.
 
> Below is the a script that illustrates the problem using some
> exaggerated settings.  You will notice that the grid is supposed to be
> in the back and the border in the front.  However, the result has the
> grid in front over the border and the data points in the 3D splot map
> but not the 2D plot.  

The front/back option for grid and border is only check for 2D plots.
3D plots follow the more complicated scheme I outlined above.  The bug
is that "set view map" should cause the 2D procedure to be used rather
than the 3D procedure.

> Another odd thing is that the colorbox shows up  on the 2D plot when
> its not needed. 

That's a separate bug. It looks like something is not reset properly
at the end of the previous plot. I wonder what?


-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: Splot map and gd.trm bugs (long)

[Daniel J S. <dan...@ie...>]

mw...@us... wrote:
> I'm using the CVS head.
> 
> I noticed a very weird problem when using 'set view map' in conjunction

[snip]

Mike,

It is alright with me if you'd like to put some effort into cleaning up tic placement in 3D.  However, let me say a couple things.

As Ethan pointed out, there are a few issues.  One is to unify code when possible, such as the example of "map" and 2D drawing should basically be the same routine.  Another issue for which I think there should be some discussion is consistent and intuitive plot layout in terms of white space at the margins and color box placement.  When I look at 3D plots, sometimes things aren't quite in balance the way I think they should be.  There is an element of not knowing the extent in 2D of a 3D image (project).  But perhaps we can come up with something to make better use of the space by default.

Also, if we are going the route of cleaning up tic placement in one or two modes, I'd like to have the group review the patch I created for tic placement (I think it was time axis or something, I can't remember exactly what) before things get changed too much that the patch needs a lot of redoing.  I'm pretty sure I can convince people of why it is a worthwhile patch... It solved a bug of dropping a tic mark at the end of an axis.

Dan