octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Matlab compatible legends for FLTK/Gnuplot backends?


From: bpabbott
Subject: Re: Matlab compatible legends for FLTK/Gnuplot backends?
Date: Tue, 07 Sep 2010 20:28:17 +0000 (GMT)

On 07 Sep, 2010,at 03:24 PM, David Bateman <address@hidden> wrote:

Ben Abbott wrote:
> On Sep 6, 2010, at 12:20 PM, David Bateman wrote:
>
>> I'm sizing the legend relative to the axis "position" property in all cases, so that things like "southoutside" might be able to align the edges of the key with the plot (though it doesn't yet). The legend itself is placed relative to the "outerposition" of the axis if the legend is "outside" of the plot. Note that I was setting the legend "position" and "outerposition" are being set to the same value in the legend axis as there are no axis labels, title, ticks etc to include. Looking at the way position and outerposition are autoupdating between themselves, this is probably not the right thing to do.
>>
>> However, with gnuplot
>>
>> plot(1,10); set (gca(), "activiepositionproperty", "position")
>>
>> doesn't give the same plot size as
>>
>> plot(1,10); set (gca(), "activiepositionproperty", "outerposition")
>>
>> which if I'm reading
>>
>> http://www.mathworks.com/help/techdoc/creating_plots/f1-32495.html
>>
>> correctly is not the right thing to happen. The fltk backend seems to get this right..
>>
>> D.
>>
>
> I don't think the fltk backend bothers with the activepositionproperty at all. Meaning it assumes the position property is active and essentially ignores the outerposition property.
>
> To match Matlab's behavior, work needs to be done in the font end to get the relationships between the position, outerposition, tightinset, and activepositionproperty working correctly.
>
Is the gnuplot behavior correct? If so then the position field of the
axis is not updated to reflect the position of the plot determined from
the outerposition. Could you tell me what are the coordinates of the
axes as determined from the outerposition.
 
I choose the current Gnuplot implementation thinking we'd also favor the ugly legend approach. Meaning both the outerposition property and the legend would be done the Gnuplot way. For the axes, this means that when the outerposition property is active, it specifies the bbox of the axes and all it's objects. When the position property is active it specifies the exact position of the plot box. For an active outerposition the postion property would not be updated, unless Gnuplot is patched to supply that info.

Given your rapid progress, I'm in favor of avoiding the ugly code.

> One quick example that illustrates a gap between Octave and Matlab ...
>
>
>>> clf
>>> axes
>>> set(gca,'outerPosition',[0.2 0.2 0.5 0.5])
>>> get(gca, 'position')
>>>
> ans = 0.265 0.255 0.3875 0.4075
>
>>> xlabel ('my label')
>>> get(gca, 'position')
>>>
> ans = 0.265 0.29048 0.3875 0.37202
>
> If I infer correctly this can be handled correctly based upon your recent work. If the position property for all axes were updated in the frontend then it would be best for the __go_draw_*.m files to ignore the outerposition ... Correct?
>
Yes, the current code would then just work.

> If my understanding is correct, then the recent changeset I made allowing the gnuplot backend to render differently depending upon the activepositionproperty will need to be reverted.
>
I see three choices

1) Revert your code as you suggest
2) Special case gnuplot in the legend function and calculate the key
position from the outerposition value
3) Get the updating of the position from the outerposition and
visa-versa working in the front-end

The first option is easy, but a step backwards, the second option is a
bad idea as it introduces a dependence on the backend in the frontend
code, and the third seems to be a large job. I'd be happy with either 1)
or 3), but probably don't have the time to do 3) myself as I think it'll
be a lot of trial and error and probably needs acces to matlab to test
that the implementation is right.

D.
 
If we do 1), I think should to go with 2) as well (and vice versa). There isn't a necessarily a need to introduce backend info in the frontend, since the properties could be parsed to produce the proper legend in Gnuplot ... well, provided the handles for the objects in the legend are listed in the properties of the legend axis.

Overall, I think 3) is the best solution.

I've studied the problem quite a bit and am willing to support someone working on it, but I'm not the right person to take the lead.

For now, I think it best to revert my outerposition changeset.

*If* it is decided to do 1)+2) both the outerposition code and the gnuplot-legend code can be reintroduced into the Gnuplot backend at the same time.

Ben

reply via email to

[Prev in Thread] Current Thread [Next in Thread]