<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Le 21/02/2018 à 12:05, Stéphane
      Mottelet a écrit :<br>
    </div>
    <blockquote cite="mid:98256e3d-9110-e818-7456-d7dc1d601c77@utc.fr"
      type="cite">Hello,
      <br>
      <br>
      The cube_scaling appeared with version 5.2 or 5.3 (I don't
      remember) because the previous default behavior, which corresponds
      to
      <br>
      <br>
      cube_scaling="off"
      <br>
      <br>
      could produce surfaces which were very hard to visualize with
      default angles and hard to homogeneously "rotate" in the elevation
      angle, when the surface is very flat. See this example:
      <br>
      <br>
      clf
      <br>
      [x,y]=meshgrid(-1:0.1:1,-2:0.1:2);
      <br>
      surf(x,y,x.*y*1e-5)
      <br>
      gca().cube_scaling="off";
      <br>
      <br>
      The default combination cube_scaling="on" and isoview="off"
      corresponds to the default behavior in Matlab. Introducing the
      cube_scaling property and its default value helps "migrating
      users" as they obtain the same thing in both softwares.
      <br>
      <br>
      Anyway, I don't think that the combination cube_scaling="off" and
      isoview="off" has still an interest as it can produce the annoying
      behavior of the above example. The default combination
      cube_scaling="on" and isoview="off" allows the 3D object to fill
      the whole 3D box whatever the proportions of the enclosing 2D
      canvas, which is the expected default behavior.
      <br>
      <br>
      Antoine's remark points out that cube_scaling="on" and
      isoview="on" produces a plot whose proportions are completely
      wrong with respect of the value of isoview="on". Adding in the
      help page of "axes_properties/isoview " a sentence such as
      <br>
      <br>
      If you want *real* isometric scales on all axes in 3D you have to
      set cube_scaling property to 'off'
      <br>
      <br>
      is not admissible.Setting the value of cube_scaling  to the
      opposite of the isoview value when the latter is changed could be
      a solution. At least, when the high level isoview *command* is
      used.
      <br>
    </blockquote>
    <br>
    The implementation of this <b>gca().cube_scaling</b> property is
    unfortunately an example of the (too) raw and fast importation of
    a feature answering in a truly awkward way to a true need.<br>
    <br>
    Extending some isometrical tunings in 3D by <i>adding</i> <i>an
      axes property </i>instead of by <i>adding some new values to the
      existing .isoview property </i>IMO was a costy error. Why ?<br>
    <ul>
      <li>adding a property whose job is not orthogonal to the <i>.isoview</i>
        one makes the whole thing puzzling, and i guess the coding as
        well. In 3D, what does this property, and what does the other
        one in a dependent way? This is really annoying.<br>
        <br>
      </li>
      <li>Due to a missing or poor initial analysis, the result is
        rather poor. The point is that we may need isometrical modes
        coupling any possible pair of directions, or even all of them.
        This is why, from the "on"|"off" values available in 2D, new
        .isoview values like "xy", "xz", "yz", "xyz" -- without creating
        any new property -- would have been more handy and powerful. And
        likely clearer and easier to code.<br>
        Then, to actually get a cubic shape whatever are the x,y and z
        scales, a last value "cube" could be possible, still without any
        new property.<br>
      </li>
    </ul>
    Analyzing a feature before implementing it has certainly a (low)
    cost. The use of some poorly built features wastes a lot more time
    for everyone and for a long time.<br>
    It's a pity.<br>
    <br>
    Regards<br>
    Samuel<br>
    <br>
  </body>
</html>