octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #40686] Incorrect colorbar size after "axis ti


From: Anne Hanna
Subject: [Octave-bug-tracker] [bug #40686] Incorrect colorbar size after "axis tight" or "axis equal"
Date: Mon, 4 Feb 2019 04:41:05 -0500 (EST)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0

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

What you say about equal and square not being the same in Gnuplot is correct. 
(They don't even belong to the same "set" subcommand --- view vs. size!) 
_However_, Gnuplot does something very odd when "set view equal xy(z)" and
"set view map" are run _in that order_, which it does not do when "set view
map" doesn't follow "set view equal xy(z)", and which it does not _undo_ when
"set view noequal" is run (in any combination).   Specifically, it sets a
locked 1:1 aspect ratio, as if you ran "set size ratio -1", and this is what
distorts the colorbar.

If you read the code for Gnuplot's internal set_view function (in set.c), you
can see this in action, although it's a little unclear why it's being done
that way.  "set size nosquare" undoes the problematic aspect ratio lock, but
if you test your proposed patch, you will (I believe) see that "set view
noequal" does not.

Aside from that, I'm a little concerned about whether the location you've
suggested for adding the correction will be side effect free.  If I'm reading
the code correctly, this would insert the "set view noequal" line after quite
a bit of the plot stream for the next piece of the figure may have already
been generated.  Given the unexpected interaction we've already seen between
"set view map" and "set view equal", and lacking a complete understanding of
all the different kinds of settings one might have wanted to do by that point
for all other types of figure components, I'm somewhat leery of sticking a new
command in the middle there for _every single plot type that's not the
problematic one_ as opposed to just having a single "undo" command at the end
of the one known-problematic plot type (the "axis equal" plot).  So that's why
I suggested putting it where I did.

Does that seem reasonable to you?

----

I should also mention a couple of other small points:

1) For all that I'm not enthusiastic about the location you suggest for
inserting the correction, it _will_ work fine for the nd == 2 case (which is
actually the one we _need_ it to work for if we want the colorbar fixed!). 
The nd == 3 test is part of the condition for the first branch, not a
condition for entering into that code block at all, so all nd == 2 plots will
go into the branch that inserts the undo command, as we would want.

2) Octave's "axis square" doesn't currently use Gnuplot's "set size square"
command, so it won't have a similar closure problem (although it might have
other ones, for all I know!).  So at least for the purposes of this bug, I
don't think it's a problem.  The original test example no longer gives me bad
results either with "axis tight" or with "axis square", so I suspect those
issues were accidentally fixed sometime in the last five years without anyone
noticing.

    _______________________________________________________

Reply to this item at:

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

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]