[Octave-bug-tracker] [bug #55859] [octave forge] (signal) zplane.m multiplicity annotations should not use superscript

[Robert Jenssen]

Follow-up Comment #11, bug #55859 (project octave):

Here is a patch that combines text shift in x and verticalalignment:

---
octave-signal-f050d888e7efe5327e5ed702aed77a8d24448616/inst/zplane.m    
2019-03-07
15:02:59.000000000 +1100
+++ signal-tip/inst/zplane.m    2019-03-10 18:40:55.529778490 +1100
@@ -115,8 +115,10 @@
       for i = 1:length (x_u)
         n = sum (x_u(i) == x(:,c));
         if (n > 1)
-          label = sprintf (" ^%d", n);
-          text (real (x_u(i)), imag (x_u(i)), label, "color", color);
+          label = sprintf ("%d", n);
+          xshift = 0.015 * diff (get (gca, "xlim"));
+          text (real (x_u(i)) + xshift, imag (x_u(i)), label, ...
+               "color", color, "verticalalignment", "bottom");
         endif
       endfor
     endfor


Unfortunately, with this change the multiplicity annotation is not placed
consistently for different sized axes. For example, if two zeros are at -2.
The markersize property is 6 points. When I resize a figure window I see that
the screen size of the marker remains constant (as expected if there is no
callback that changes the markersize to match the new window size). To
correctly space the multiplicity annotation I'd have to be able to find the
difference between the axis x limits in points. I don't know how to do this in
the current Octave. For example:

octave:1> h=plot (1/2, 1/2, "linestyle", "none", "marker", "x");
octave:2> cu=get(gca(),"units")
cu = normalized
octave:3> get(gca(),"xlim")
ans =

   0.44000   0.58000

octave:4> get(gca(),"position")
ans =

   0.13000   0.11000   0.77500   0.81500

octave:5> set(gca(),"units","points")
octave:6> get(gca(),"xlim")
ans =

   0.44000   0.58000

octave:7> get(gca(),"position")
ans =

    54.576    34.635   325.358   256.613


When I change the units the "xlim" doesn't change. When I resize the figure
window, the "position" doesn't change. This seems to me to be a bug.

    _______________________________________________________

Reply to this item at:

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

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