improving axes property behavior for the gnuplot backend

[Ben Abbott]

On Nov 15, 2008, at 10:18 AM, Ben Abbott wrote:

>
> 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.

I've just realized that "tightinset" is only readable from the  
console, and that the interaction of position/outerpostion/tightinset  
and their dependence upon other axes properties is not yet handled any  
where (that I can find).

For the gnuplot backend it would be easy enough to handle such  
relationships using m-files, but  as this interaction is (and many  
others are) not specific to the backend implementation, where should  
this functionality go?

For the moment, I have a m-file that calculates the tightinset. While  
I can optionally use that script when get(hax,"tightinset") returns  
zeros, such an implementation is not exactly pretty.

I''d think it preferable that a backend agnostic solution for such  
things be written (another example  is the relationship between  
papertype, papersize, and paperposition).

In any event, what should be done, and is anyone with the needed  
skills interested?

Ben