Re: Matlab compatible legends for FLTK/Gnuplot backends?

[Ben Abbott]

On Sep 5, 2010, at 11:02 PM, David Bateman wrote:

> Ben Abbott wrote:
>> On Sep 5, 2010, at 6:41 PM, David Bateman wrote:
>> 
>>  
>>> 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.
>>>> 
>>>>      
>>> Well here is a first implementation that use method 1) above. I'm sure 
>>> there are some things missing, for example the method of using the 
>>> "annotation" field of the graphics objects to decide if they are included 
>>> in the legend ass described in
>>> 
>>> http://www.mathworks.com/help/techdoc/creating_plots/braliom.html
>>> 
>>> and its seems the legend and the extra fields of the legend axis
>>> 
>>> 'EdgeColor'
>>> 'Interpreter'
>>> 'Location'
>>> 'Orientation'
>>> 'String'
>>> 'TextColor'
>>> 
>>> as described in
>>> 
>>> https://savannah.gnu.org/bugs/?30461
>>> 
>>> The patch does however implement legends with different parents and 
>>> horizontal legends. So it fixes the bugs
>>> 29348, 30461 and in passing partially fixes the bug  30519.
>>> 
>>> It seems to work pretty well for the FLTK backend, and with a few hacks, it 
>>> works ok for me with the WXT terminal of gnuplot. It hasn't received a lot 
>>> of testing with gnuplot however, and I'm sending it now as I'm not sure 
>>> I'll have much time to work on this in the next couple of days.
>>> 
>>> So the questions I have are
>>> 
>>> a) If we keep the approach in this patch as described in method 1) above is 
>>> the need for FreeType and font_config to be installed an acceptable 
>>> limitation? These would become required rather than just optional
>>> 
>>> b) Is the approximate behavior of the text extents returned by FreeType for 
>>> the gnuplot terminal good enough? It needs more testing.
>>> 
>>> c) Why do I need to set the plot axis "activepositionproperty" to 
>>> "position" for the gnuplot backend to get the legend to display correctly? 
>>> I see no reason for this need.
>>> 
>>> d) I worked internally in the legend function in "points" as by default the 
>>> text extents were returned in points. Would it be better to work in pixels 
>>> as that is what the figure position returns by default?
>>> 
>>> If the answer to a) and b) are "yes" I'll continue to work this up as a 
>>> changeset, cleaning out the old dead legend code and finishing fixing bug 
>>> 30519 (rather than just the minimum to get legends working). Otherwise I'll 
>>> need to consider about how to implement method 3) above in a clean manner.
>>> 
>>> Regards
>>> David
>>>    
>> 
>> I haven't looked into the details. The FLTK backend gave me the expected 
>> result. Gnuplot gave me something else ... plots attached. I do have both 
>> FreeType and font_config installed.
>> 
>> The script I used was ...
>> 
>> clf
>> x= 0:0.1:10;
>> plot (x, sin(x), x, cos(x))
>> legend ({"sin(x)", "cos(x)"}, "location", "northeast")
>> 
>> Tomorrow I'll look closer, but if anyone has an idea, I'd appreciate 
>> suggestions.
>> 
>> Ben
>> 
> I'm not seeing this with gnuplot 4.2.6. Though I do with gnuplot 4.4.0. If 
> you add
> 
> set (gca(), "activepositionproperty", "outerposition")
> 
> after the call to legend in gnuplot 4.4.0, I get the same behavior as for 
> gnuplot 4.2.6 where the legend is compressed and badly placed. I'd say it 
> looks like an issue in __go_draw_* code for the parsing of the position and 
> outerposition parameters for use with gnuplot rather than in the legend code.
> 
> D.

*** I'm sending this a second time without the attachment so that it doesn't 
get hung up waiting for moderator approval ***

I ran some tests changing the activepositionproperty for both axes and for each 
version of gnuplot (see my attached plots).

If you change the snippet below ....

       ## FIXME A hack for gnuplot. God knows why this is needed
       if (strcmp (get (fig, "__backend__"), "gnuplot"))
         set (ca(1), "activepositionproperty", "position");
       endif

... to ...

         set (hlegend, "activepositionproperty", "position");

The legend looks correct. This is also the value that Matlab assigns to 
activepositionproperty for the legend. 

However, that doesn't address the problem seen when running gnuplot 4.4, 
setting the gca's activeposition  to "position" and the legend's activepositon 
to "outerposition". I'll take a look at that.

Ben