Menu ▾ ▴

#2287 "set view equal xy(z); set view map" has hidden and inconsistent side effects

None
closed-fixed
nobody
None
2021-12-25
2020-06-27
Anne Hanna
No

Running the commands "set view equal xy(z); set view map" in that order, but not in the reverse order sets the aspect ratio to a locked value of 1:1 (equivalent to "set size ratio -1"), in a way that cannot be undone by any subsequent "set view" or "unset view" commands (including, e.g., "set view noequal"). Only specifically adjusting or unsetting the aspect ratio via "set size" commands (e.g., "set size ratio <value>", "set size noratio", or "set size nosquare") can undo the aspect ratio lock.</value>

The section of set_view() dealing with "set view map" seems to lock the aspect ratio on purpose when a 3D aspect ratio has been previously set (at https://sourceforge.net/p/gnuplot/gnuplot-main/ci/master/tree/src/set.c#l5511), but "set view equal xy(z)" does not check if we're in a map view and try to do the same. Conversely, leaving "equal" view (via "set view noequal") does not attempt to undo the lock. I don't fully understand the design philosophy of these various view modes, but having a silent, undocumented, order-dependent, and difficult to reverse side effect that ordinarily belongs to an entirely different command seems like it violates the way a user would expect these commands to work.

This issue has been present for a while and seems to remain in the current "master" branch of the codebase. (I'm currently running gnuplot 5.2 patchlevel 8 under Debian unstable, if you need a specific known-bad reference point. The relevant code seems to have been introduced by commit #9f20498f79bd7d50e78f9a85fd54c02b8af0e456, entitled 'coordinate 2D and 3D aspect ratio flags from "set view map" and "set view equal xy"', made by Ethan Merritt.) I first noticed it because it's associated with a long-running bug in how Octave draws colorbars on splots when using gnuplot graphics toolbox (https://savannah.gnu.org/bugs/?40686). The Octave bug isn't gnuplot's fault, but the gnuplot issue made it more confusing to find a fix, so it would be nice to have this fixed to make it more consistent somehow. Or, if it's deliberate for some reason, it would be useful if it were better explained and justified in the documentation.

Discussion

  • Anne Hanna

    Anne Hanna - 2020-06-27
    • Description has changed:

    Diff:

    --- old
+++ new
@@ -1,6 +1,5 @@
 Running the commands &#34;set view equal xy(z); set view map&#34; *in that order, but not in the reverse order* sets the aspect ratio to a locked value of 1:1 (equivalent to &#34;set size ratio -1&#34;), in a way that cannot be undone by any subsequent &#34;set view&#34; or &#34;unset view&#34; commands (including, e.g., &#34;set view noequal&#34;).  Only specifically adjusting or unsetting the aspect ratio via &#34;set size&#34; commands (e.g., &#34;set size ratio &lt;value&gt;&#34;, &#34;set size noratio&#34;, or &#34;set size nosquare&#34;) can undo the aspect ratio lock.

-The section of set_view() dealing with &#34;set view map&#34; seems to lock the aspect ratio on purpose when a 3D aspect ratio has been previously set (at https://sourceforge.net/p/gnuplot/gnuplot-main/ci/master/tree/src/set.c#l5511), but &#34;set view equal xy(z)&#34; does not check if we&#39;re in a map view and try to do the same.  Conversely, leaving &#34;equal&#34; view does not attempt to undo the lock.  I don&#39;t fully understand the design philosophy of these various view modes, but having a silent, undocumented, order-dependent, and difficult to reverse side effect that ordinarily belongs to an entirely different command seems like it violates the way a user would expect these commands to work.
+The section of set_view() dealing with &#34;set view map&#34; seems to lock the aspect ratio on purpose when a 3D aspect ratio has been previously set (at https://sourceforge.net/p/gnuplot/gnuplot-main/ci/master/tree/src/set.c#l5511), but &#34;set view equal xy(z)&#34; does not check if we&#39;re in a map view and try to do the same.  Conversely, leaving &#34;equal&#34; view (via &#34;set view noequal&#34;) does not attempt to undo the lock.  I don&#39;t fully understand the design philosophy of these various view modes, but having a silent, undocumented, order-dependent, and difficult to reverse side effect that ordinarily belongs to an entirely different command seems like it violates the way a user would expect these commands to work.

-This issue has been present for a while and seems to remain in the current &#34;master&#34; branch of the codebase.  (I&#39;m currently running gnuplot 5.2 patchlevel 8 under Debian unstable, if you need a specific known-bad reference point.  The relevant code seems to have been introduced by commit #9f20498f79bd7d50e78f9a85fd54c02b8af0e456, entitled &#39;coordinate 2D and 3D
-aspect ratio flags from &#34;set view map&#34; and &#34;set view equal xy&#34;&#39;, made by Ethan Merritt.)  I first noticed it because it&#39;s associated with a long-running bug in how Octave draws colorbars on splots when using gnuplot graphics toolbox (https://savannah.gnu.org/bugs/?40686).  The Octave bug isn&#39;t gnuplot&#39;s fault, but the gnuplot issue made it more confusing to find a fix, so it would be nice to have this either fixed to make it more consistent somehow.  Or, if it&#39;s deliberate for some reason, it would be useful if it were better explained and justified in the documentation.
+This issue has been present for a while and seems to remain in the current &#34;master&#34; branch of the codebase.  (I&#39;m currently running gnuplot 5.2 patchlevel 8 under Debian unstable, if you need a specific known-bad reference point.  The relevant code seems to have been introduced by commit #9f20498f79bd7d50e78f9a85fd54c02b8af0e456, entitled &#39;coordinate 2D and 3D aspect ratio flags from &#34;set view map&#34; and &#34;set view equal xy&#34;&#39;, made by Ethan Merritt.)  I first noticed it because it&#39;s associated with a long-running bug in how Octave draws colorbars on splots when using gnuplot graphics toolbox (https://savannah.gnu.org/bugs/?40686).  The Octave bug isn&#39;t gnuplot&#39;s fault, but the gnuplot issue made it more confusing to find a fix, so it would be nice to have this either fixed to make it more consistent somehow.  Or, if it&#39;s deliberate for some reason, it would be useful if it were better explained and justified in the documentation.
    • Group: -->
    • Priority: -->
     

  • Anne Hanna

    Anne Hanna - 2020-06-27
    • Description has changed:

    Diff:

    --- old
+++ new
@@ -2,4 +2,4 @@

 The section of set_view() dealing with &#34;set view map&#34; seems to lock the aspect ratio on purpose when a 3D aspect ratio has been previously set (at https://sourceforge.net/p/gnuplot/gnuplot-main/ci/master/tree/src/set.c#l5511), but &#34;set view equal xy(z)&#34; does not check if we&#39;re in a map view and try to do the same.  Conversely, leaving &#34;equal&#34; view (via &#34;set view noequal&#34;) does not attempt to undo the lock.  I don&#39;t fully understand the design philosophy of these various view modes, but having a silent, undocumented, order-dependent, and difficult to reverse side effect that ordinarily belongs to an entirely different command seems like it violates the way a user would expect these commands to work.

-This issue has been present for a while and seems to remain in the current &#34;master&#34; branch of the codebase.  (I&#39;m currently running gnuplot 5.2 patchlevel 8 under Debian unstable, if you need a specific known-bad reference point.  The relevant code seems to have been introduced by commit #9f20498f79bd7d50e78f9a85fd54c02b8af0e456, entitled &#39;coordinate 2D and 3D aspect ratio flags from &#34;set view map&#34; and &#34;set view equal xy&#34;&#39;, made by Ethan Merritt.)  I first noticed it because it&#39;s associated with a long-running bug in how Octave draws colorbars on splots when using gnuplot graphics toolbox (https://savannah.gnu.org/bugs/?40686).  The Octave bug isn&#39;t gnuplot&#39;s fault, but the gnuplot issue made it more confusing to find a fix, so it would be nice to have this either fixed to make it more consistent somehow.  Or, if it&#39;s deliberate for some reason, it would be useful if it were better explained and justified in the documentation.
+This issue has been present for a while and seems to remain in the current &#34;master&#34; branch of the codebase.  (I&#39;m currently running gnuplot 5.2 patchlevel 8 under Debian unstable, if you need a specific known-bad reference point.  The relevant code seems to have been introduced by commit #9f20498f79bd7d50e78f9a85fd54c02b8af0e456, entitled &#39;coordinate 2D and 3D aspect ratio flags from &#34;set view map&#34; and &#34;set view equal xy&#34;&#39;, made by Ethan Merritt.)  I first noticed it because it&#39;s associated with a long-running bug in how Octave draws colorbars on splots when using gnuplot graphics toolbox (https://savannah.gnu.org/bugs/?40686).  The Octave bug isn&#39;t gnuplot&#39;s fault, but the gnuplot issue made it more confusing to find a fix, so it would be nice to have this fixed to make it more consistent somehow.  Or, if it&#39;s deliberate for some reason, it would be useful if it were better explained and justified in the documentation.
     

  • Ethan Merritt

    Ethan Merritt - 2021-12-03
    • status: open --> pending-fixed
     

  • Ethan Merritt

    Ethan Merritt - 2021-12-03

    Now fixed in 5.5
    May be back-ported for a later 5.4 stable release.

     

  • Ethan Merritt

    Ethan Merritt - 2021-12-25
    • Status: pending-fixed --> closed-fixed
     

Log in to post a comment.