On Nov 15, 2008, at 4:43 AM, David Bateman wrote:
Ben Abbott wrote:
As implemented today, the gnuplot backend does not properly
respect the "outerposition", "position" and
"activepositionproperty" properties for the axes. For the gnuplot
backend to do so a rather signficant change to __go_draw_axes__.m
is needed.
I'm thinking about taking that on. Before begining I wanted
solicit comments/concernts/objections.
In order to ensure that the "position" and "outerpostion" are
rendered properly and are consistent across different terminals, I
suspect it will also be necessary to replace the gnuplot x/y/
zlabel commands with
set label {<tag>} {"<label text>"}
{at {<system>} <x>, {<system>} <y> {,{<system>} <z>}}
{left | center | right}
{norotate | rotate {by <degrees>}}
{font "<name>{,<size>}"}
{noenhanced}
{front | back}
{textcolor <colorspec>}
{point <pointstyle> | nopoint}
{offset <offset>}
Again, before I begin does anyone have any comments/concerns/
objections?
Ben
p.s. ticklabels might also be explicitly positioned by Octave, but
that
can wait.
Yes the labels and legends pose a problem in getting this right..
Essentially, the intelligence on the placement of the labels need
to be moved from gnuplot to Octave. The "set margin" commands that
were added recently to __go_draw_axes__ have to be kept to allow
plot alignment with subplot and plotyy to be respected. This
essentially means that gnuplot backend always uses the Position
axis property and its upto Octave to ensure that Position is
updated wrt OuterPosition and the labeling.
Finally, subplot uses the OuterPosition to determine the position
in the subplot grid, which seems to be matlab compatibility.
However, this means that adding a colorbar axis requires that the
outerposition is kept constant but the position is adjusted to
respect the presence of the colorbar axis. So there are lots of
corner cases to consider in the change you propose...
ok, to be honest I haven't looked at the details of plotyy since
your changeset. However, the present behavior of subplot is one
reason why I thought this needed some attention ... some terminals
look nice and others are way to spacious ;-)
I'll look over how "set margin" is presently used as well.
I plan to use "tightinset" in the same manner that I understand the
competitor does. So I'll start with that and see what problems I run
into. Determining the dimentions of tex/enhanced strings will be
tricky (which may be why the competitor requires that ticklabels
have interpreter='none').
If anyone has a thought on a sloppy, quick, and reasonably accurate
method to determine the rendered length of a tex/enhanced string,
please point me in that direction.