[Octave-bug-tracker] [bug #40686] Incorrect colorbar size after "axis tight" or "axis equal"

[Anne Hanna]

Follow-up Comment #5, bug #40686 (project octave):

I have recently been experiencing problems with colorbar lengths after "axis
equal" on a pcolor plot in Octave 4.4.1 using the gnuplot graphics tookit
(under Debian Linux).  I believe my problems are related to those discussed in
this bug report, and I have some diagnostic information that may be useful in
resolving it, after all these years.

In attempting to diagnose my issue, I dumped the plot stream to text files and
played around with it in gnuplot.  I confirmed that the problematic part of
the gnuplot stream is the same in my own code as in the MWE given in comment
#4.  However, either the relevant parts of Octave have changed somewhat since
#4 was written, or #4 was tested with a different graphics toolkit that might
have different bugs in it.  With gnuplot 5.2 and Octave 4.4.1, "axis tight" is
not required for the problem to manifest, and "axis square" does not cause it,
with or without "axis tight".  So a current version of that MWE seems to be:


 clf;
 [x, y, z] = peaks ();

 pcolor (x, y, z);

 axis equal
# axis normal       # Uncomment this line to make the problem go away.
 cb(1) = colorbar ();


An even more egregious shrinking of the colorbar under "axis equal" occurs
with my original test case, which was:


 clf
 pcolor(round(rand([5, 3])))
 axis equal
# axis normal       # Uncomment this line to make the problem go away.
 colorbar


The only significant difference between the "axis equal" and "axis normal"
plot streams in both MWEs is the presence of "set view equal xyz" near the
beginning of the "axis equal" plot stream.  It seems that this use of "set
view equal" does not play nicely with the later use of "set view map" to
reorient the "three-dimensional" pcolor plot to be shown face-on.  If I change
"set view map" to "set view 0,0" in my plot stream file and run it in gnuplot,
the colorbar attains its correct height and the rest of the image seems (to my
eye) to be correct.

We can see in the __gnuplot_draw_axes__ function that "set view map" is only
used for "surface" type graphics objects, and then only under the following
circumstance (line 1684):


 if (view_map && rot_x == 0 && rot_z == 0)


I don't think I understand the code well enough to see why graphs with these
properties need map view rather than just an appropriate rotation (i.e., "set
view 0,0"), but perhaps someone who understands this better than I can tease
out 
the reason and decide what the best fix is?

---------

The reason that "axis square" and "axis tight" are no longer relevant to this
problem can also be seen in the __gnuplot_draw_axes__ function.  A "set view
equal" command is inserted only under the following circumstance (lines
120-122):


  if (nd == 3 &&
      strcmp (axis_obj.dataaspectratiomode, "manual") &&
      axis_obj.dataaspectratio(1) == axis_obj.dataaspectratio(2))


Using "axis square" instead of "axis equal" currently causes axis_obj to fail
this test (dataaspectratiomode is "auto"), so "set view equal xyz" is never
set for the main plot and the problem does not occur.  "axis tight" doesn't
affect the parameters checked by this test, so it doesn't help trigger the bug
either.

Anyway, I hope this helps with the bug somewhat?  Not being able to have
usable colorbars on these plots is making me crazy.  :D

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?40686>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/