Re: Matlab compatible legends for FLTK/Gnuplot backends?

[Ben Abbott]

On Sep 1, 2010, at 3:14 PM, David Bateman wrote:

> As it seems to me that the blocking feature for 3.4.0 is the support of 
> legends in FLTK, I've been looking at writing a matlab compatiable, or at 
> least more compatible than currently, legend function. I however want this 
> function to not be specific to a backend and I want it to work with both FLTK 
> and the gnuplot backend and be implemented entirely as a frontend function. 
> I'm however blocked in that goal when calculating the extents of the text 
> strings.
> 
> How I'm trying to implement this function is to create an axis object, with 
> the "tag" property set to "legend" and the userdata with a structure with a 
> field pointing to the axis the legend is attached to. The position, limits, 
> etc of the legend axis are initially arbitrary and into this axis I write all 
> of the text strings. The object of doing this is to calculate the extent of 
> each of the text strings so that I can then select an optimal positioning of 
> the keys in the legend, and only after that resize the axis, position it and 
> write the symbols. The get_extents method of the graphics.cc(text) class 
> fills in the "extents" property of the text objects. However, it relies on 
> having both FreeType and font_config installed. I'd rather not add new 
> dependency for the gnuplot backend and in any case why should I assume that 
> FreeType will give extents that are compatible with gnuplot. So from here I 
> see I have one of four choices
> 
> 1) Accept the FreeType and font_config dependencies, making these essential 
> for any plotting with legends in Octave. However, this might not be ideal for 
> the gnuplot backend,
> 
> 2) Try and find another means of implementing the get_extents method of the 
> the graphics.cc(text) class that will be used if FreeType isn't installed (or 
> for backends that don't use FreeType), but this is likely to be approximative
> 
> 3) Give up on trying to have a legend function that is implemented entirely 
> in the frontend and  continue to use gnuplot itself for the legend insertion 
> for the gnuplot backend. I'd probably implement the missing horizontal legend 
> orientation in gnuplot and make the gnuplot legend more compatible with 
> matlab in this case.
> 
> 4) Get someone on this list to tell me I'm a bloody idiot and there is 
> another means of getting the text extents that will be correct (at least 
> approximately) for all backends.
> 
> I'm kind of hoping for 4), but failing that help in choosing which of the 
> other three options would be appreciated
> 
> D.


Implementing the legend the Matlab way with Gnuplot will get even messier, if 
we need to handle the outerposition property in the manner Matlab does. I 
recommend we continue to implement the legend for the Gnuplot backend using 
Gnuplot's key.

However, I see no need to keep the axes "key*" properties in place.

A Matlab compatible legend has additional properties ...

    'EdgeColor'
    'Interpreter'
    'Location'
    'Orientation'
    'String'
    'TextColor'

If we also include a list of handles for the objects listed in the legend, then 
it will be possible to parse the information in the front end (i.e. properties) 
and use Gnuplot's key to produce the desired legend.

Ben