Re: The future of draw_axes

[Ben Abbott]

On Jan 22, 2011, at 4:47 PM, David Bateman wrote:

> logari81 wrote:
>> On Sat, 2011-01-22 at 22:22 +0100, David Bateman wrote:
>> 
>>> Ben Abbott wrote:
>>> 
>>>> On Jan 22, 2011, at 5:58 AM, logari81 <address@hidden> wrote:
>>>> 
>>>>> I think that freetype will be at some point in the future a prerequisite
>>>>> for octave anyway, even when using gnuplot, just for estimating text
>>>>> extents.
>>>>> 
>>>>> 
>>>> Good point.
>>>> 
>>> This is what I tried with the legend code. Trying to estimate the text
>>> extents with FreeType when for example gnuplot is using something else
>>> (gd, etc) gives pretty poor results. This is why I ended up treating the
>>> gnuplot legends  with the gnuplot legend functionality rather than using
>>> an overlaid axis with appropriate line and text objects.
>>> 
>>> Kostas, if you figure out a way to get good text extents for gnuplot
>>> I'll applaud and then go and make the gnuplot legend code much simpler.
>>> However, I think it'll be really hard to get it right, and probably the
>>> only way is to have gnuplot modified to supply the means to give them to us.
>>> 
>>> D.
>> 
>> My idea is to split the job currently done in draw_axes into two parts:
>> 
>> 1. Preparing the layout: calculation of objects (ticks, labels, etc.)
>> positions relatively to the axes.
>> 
>> 2. Drawing the objects at the pre-calculated positions. Pure openGL
>> operations.
>> 
>> I would like to have (1) in graphics.cc so that it can possibly (but not
>> necessarily) be used by gnuplot as well.
>> 
>> I would leave (2) in draw_axes, keeping in it only the pure OpenGL part.
>> 
>> My main motivation is not the improvement of the gnuplot backend (this
>> could be a side effect). My real objective is to solve the
>> position/outerposition/tightinset synchronization problem in fltk.
>> 
>> I think my recent changes have tided up draw_axes a bit, so that
>> separating the layout calculation from the drawing operation would now
>> be easier than before.
>> 
>> BR
>> 
>> Kostas
>> 
> I just think that in your point 1) you won't have good text extent
> calculations for the gnuplot backend unless we can get gnuplot to give
> these itself. The rest you should be able to do for both gnuplot and
> fltk in a consistent manner.
> 
> D.

Regarding the gnuplot backend, If a "positionmode" property [ {auto} | manual ] 
were added to the axes label's text objects, then it would be possible to (1) 
detect if the position was changed manually, (2) toogle it on/off to determine 
the offset from the nominal case, (3) add the offset to axis labels in order to 
get the desired visual effect.

The actual positions wouldn't be correct (since the extents would only be 
approximate), but the visual result should be ok.

If the estimated extents aren't good enough to be used to render the 
position/outerposition/tightinset/legend features, we can use populate the 
properties and leave the current "do it the gnuplot way" implementation in 
place.

Ben