Proposed 'position' change

[Daniel J Sebald]

I'm not sure exactly how 'position' in the Matryoska Tags is supposed to be handled.  Right now it appears to be forced to [0 0 1 1] inside __go_draw_axes__.m.  I'd like to propose the change in the attached patch.

The issue is that there isn't much control of the plot borders right now.  I wanted to do something like

  pos = get(gca, 'position')
  pos(1) = 0.1
  set(gca, 'position', pos);

in order to get some subplots to line up nicely along all vertical borders.  Instead Octave does nothing in response to the position, for the reason described above.

The change I propose is to define 'NaN' to mean "auto-compute" the borders.  If a position value is not NaN, gnuplot is instructed to use the specified margin.  With this interpretation and a default of [NaN NaN NaN NaN] the above sequence of commands would produce

  plot(...)
  pos = get(gca, 'position')
pos = [NaN NaN NaN NaN]
  pos(1) = 0.1
pos = [0.1 NaN NaN NaN]

which means that the left margin is fixed and the rest are auto-computed by gnuplot.  Basically, calling set() achieves what I wanted.  (If the actual values were returned in the pos array, that would still work too.)

There are a couple snags.  First, does pos mean [lmargin bmargin rmargin tmargin]?  Or [lmargin bmargin width height]?  The latter is problematic because there really is no way of having auto-computed quantities for the right and top borders.  (Auto-computing a width makes little sense.)  Second, it would be nice if gnuplot could return the actual values so that the NaN isn't needed.  Would gnuplot indicating the actual quantities help in any way?  E.g.,

gnuplot> show margin

        lmargin is set to 0.15
        bmargin is computed automatically (0.04)
        rmargin is computed automatically (0.95)
        tmargin is computed automatically (0.95)

which I could propose as a change to gnuplot?

Dan

--- graphics.cc 2008-02-06 04:46:10.000000000 -0600
+++ /usr/local/src/octave-cvs/octave/src/graphics.cc 2008-10-02 22:35:19.000000000 -0500
@@ -146,10 +146,10 @@
 default_axes_position (void)
 {
   Matrix m (1, 4, 0.0);
-  m(0) = 0.13;
-  m(1) = 0.11;
-  m(2) = 0.775;
-  m(3) = 0.815;
+  m(0) = NaN;
+  m(1) = NaN;
+  m(2) = NaN;
+  m(3) = NaN;
   return m;
 }
 
--- /usr/local/share/octave/3.0.0+/m/plot/__go_draw_axes__.m 2008-01-30 21:13:52.000000000 -0600
+++ __go_draw_axes__.m 2008-10-02 17:59:03.000000000 -0500
@@ -32,7 +32,6 @@
       = compare_versions (__gnuplot_version__ (), "4.0", ">");
 
     ## Set axis properties here?
-    pos = [0, 0, 1, 1];
     if (strcmp (axis_obj.activepositionproperty, "outerposition"))
       ymirror = true;
       if (! isempty (axis_obj.outerposition))
@@ -57,6 +56,29 @@
     fprintf (plot_stream, "set origin %.15g, %.15g;\n", pos(1), pos(2));
     fprintf (plot_stream, "set size %.15g, %.15g;\n", pos(3), pos(4));
 
+    if (! isempty (axis_obj.position))
+      if (isnan(axis_obj.position(1)))
+ fprintf (plot_stream, "set lmargin;\n");
+      else
+ fprintf (plot_stream, "set lmargin at screen %.15g;\n", axis_obj.position(1));
+      endif
+      if (isnan(axis_obj.position(2)))
+ fprintf (plot_stream, "set bmargin;\n");
+      else
+ fprintf (plot_stream, "set bmargin at screen %.15g;\n", axis_obj.position(2));
+      endif
+      if (isnan(axis_obj.position(3)))
+ fprintf (plot_stream, "set rmargin;\n");
+      else
+ fprintf (plot_stream, "set rmargin at screen %.15g;\n", axis_obj.position(3));
+      endif
+      if (isnan(axis_obj.position(4)))
+ fprintf (plot_stream, "set tmargin;\n");
+      else
+ fprintf (plot_stream, "set tmargin at screen %.15g;\n", axis_obj.position(4));
+      endif
+    endif
+
     if (strcmpi (axis_obj.dataaspectratiomode, "manual"))
       r = axis_obj.dataaspectratio;
       fprintf (plot_stream, "set size ratio %.15g;\n", -r(2)/r(1));

[Michael Goffioul-2]

On Fri, Oct 3, 2008 at 6:16 AM, Daniel J Sebald <daniel.sebald@...> wrote:
> There are a couple snags.  First, does pos mean [lmargin bmargin rmargin
> tmargin]?  Or [lmargin bmargin width height]?

Position means [x y width height].

Note also that computing position should also somehow takes
into account the Units property.

Michael.

[Ben Abbott]

On Friday, October 03, 2008, at 12:16AM, "Daniel J Sebald" <daniel.sebald@...> wrote:
>I'm not sure exactly how 'position' in the Matryoska Tags is supposed to be handled.  Right now it appears to be forced to [0 0 1 1] inside __go_draw_axes__.m.

Daniel,

I'm guessing you're using Octave 3.0.2 (I haven't checked 3.0.3).

The "position" code has been modified substantially between 3.0.x and the current develoopers sources 3.1.51+

I'd suggest you work with the sources for 3.0.3, and offer patches to that branch (perhaps you already are).

    http://artax.karlin.mff.cuni.cz/~hajej2am/ulozna/octave/ 

... or work with the developers sourses and patch those (if the problem is even there).

Ben

[Ben Abbott]

 
On Friday, October 03, 2008, at 08:45AM, "Ben Abbott" <bpabbott@...> wrote:
>On Friday, October 03, 2008, at 12:16AM, "Daniel J Sebald" <daniel.sebald@...> wrote:
>>I'm not sure exactly how 'position' in the Matryoska Tags is supposed to be handled.  Right now it appears to be forced to [0 0 1 1] inside __go_draw_axes__.m.
>
>Daniel,
>
>I'm guessing you're using Octave 3.0.2 (I haven't checked 3.0.3).

Opps. nix that. I missed the line in 3.1.51+.

Sorry

Ben

[Daniel J Sebald]

Michael Goffioul wrote:

> On Fri, Oct 3, 2008 at 6:16 AM, Daniel J Sebald <daniel.sebald@...> wrote:
>
>>There are a couple snags.  First, does pos mean [lmargin bmargin rmargin
>>tmargin]?  Or [lmargin bmargin width height]?
>
>
> Position means [x y width height].
>
> Note also that computing position should also somehow takes
> into account the Units property.

Is there an "auto-compute" concept then?  Having an auto-computed (x,y) and fixed (width,height) doesn't make sense.

What do you mean by Units?  We're talking position of the axes, so the only units are relative to subplot, right?

Dan

[Daniel J Sebald]

Ben Abbott wrote:

> On Friday, October 03, 2008, at 12:16AM, "Daniel J Sebald"
> <daniel.sebald@...> wrote:
>
>> I'm not sure exactly how 'position' in the Matryoska Tags is
>> supposed to be handled.  Right now it appears to be forced to [0 0
>> 1 1] inside __go_draw_axes__.m.
>
>
> Daniel,
>
> I'm guessing you're using Octave 3.0.2 (I haven't checked 3.0.3).

No, I'm still on 3.0.0.  I haven't gotten Mercurial to work (missing recent python version).  I did check the Mercurial web interface, and __go_draw_axes__ looked the same.

I'll see if I can get up-to-date soon.

Dan

[Michael Goffioul-2]

On Fri, Oct 3, 2008 at 2:52 PM, Daniel J Sebald <daniel.sebald@...> wrote:
> Is there an "auto-compute" concept then?  Having an auto-computed (x,y) and
> fixed (width,height) doesn't make sense.
>
> What do you mean by Units?  We're talking position of the axes, so the only
> units are relative to subplot, right?

Units means the current units used for Position and OuterPosition properties.
This can be Normalized, and the axes is then rescaled with window resize,
or fixed (centimeters, inches, points...), and the axes does not
change (relative
to lower-left corner) when the window is resized.

When you express Position or OuterPosition, you should take the current
Units into account.

Michael.

[dbateman]

Daniel J Sebald wrote:

Is there an "auto-compute" concept then?  Having an auto-computed (x,y) and fixed (width,height) doesn't make sense.

I fully suppport a change something like this, and in fact the colorvar, plotyy patch I circukated included something like this. Yes some auto-computation in octave is necessry to get things to line up, and must inlude in the calculation

1) tic label size
2) x/y/z label sizes that are font dependent
3) ditto for the title
4) presence and size of the colorbar
5) ActivePositionProperty and feedback from the graphics backend when doing window resizing

Of course Octave does none of this yet and previously relied on the automatic scaling of gnuplot. But to get things right that intellige

[dbateman]

Daniel J Sebald wrote:

Is there an "auto-compute" concept then?  Having an auto-computed (x,y) and fixed (width,height) doesn't make sense.

I fully suppport a change something like this, and in fact the colorbar, plotyy patch I circulated included something like this. Yes some auto-computation in octave is necessary to get things to line up, and must include in the calculation

1) tic label size
2) x/y/z label sizes that are font dependent
3) ditto for the title
4) presence and size of the colorbar
5) ActivePositionProperty and feedback from the graphics backend when doing window resizing

Of course Octave does none of this yet and previously relied on the automatic scaling of gnuplot. But to get things right that intelligence must be moved back into Ocatve. In any case the reason my colorbar/plotyy patch isn't commit are some issue with updating axis properties mixed with callback functions in the axis code that no one seems to be able to find the bug. In any case I'd encourage you to work from the base of my patch that I can send offline if you are interested and with Octave 3.1.51+

As for details on how this calculation should be done for compatibility,see


http://www.mathworks.com/access/helpdesk/help/techdoc/index.html?/access/helpdesk/help/techdoc/creating_plots/f1-32495.html

D.

PS sorry for the partial post previous, as I writing with a baby in my arms :-)