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