Re: Outerposition Patch

[Ben Abbott]

On Feb 13, 2011, at 12:05 PM, logari81 wrote:

> On Thu, 2011-02-10 at 20:00 +0100, Konstantinos Poulios wrote:
>> On Thu, Feb 10, 2011 at 1:59 PM, Konstantinos Poulios
>> <address@hidden> wrote:
>>> On Thu, Feb 10, 2011 at 9:25 AM, David Bateman <address@hidden> wrote:
>>>> 
>>>> Le 10 févr. 2011 à 00:25, logari81 <address@hidden> a écrit :
>>>> 
>>>>>> 
>>>>> thank you for this information.
>>>>> 
>>>>> It seems that the previously attached patch causes problems only with
>>>>> legends. However, in order to treat legends correctly I need to
>>>>> understand their logic. How do legends exploit the outerposition and
>>>>> position properties? Is anyone familiar with legend.m to give me a short
>>>>> introduction?
>>>>> 
>>>>> Best regards
>>>>> 
>>>> You shouldn't try to understand the logic of legend's use of the position 
>>>> and outerposition properties. It's just a hack that worked with the 
>>>> existing behavior. If your patch doesn't work well with legend it is 
>>>> probably legend that needs to be fixed
>>>> 
>>>> D.
>>> 
>>> The attached patch replaces the previous one and implements the
>>> calculation of both position and outerposition depending on the value
>>> of activepositionproperty.
>>> 
>>> It is not very well tested yet, so there will probably be some issues,
>>> e.g. legends will not work, but it brings a feature that maybe is
>>> awesome. It is something that Matlab cannot do and maybe you like it.
>>> See the following video:
>>> 
>>> http://ubuntuone.com/p/cYM/
>>> 
>>> The position property is calculated dynamically while you rotate the
>>> view, so that all labels fit in outerposition. I think it works quite
>>> well in order to keep it. What do you think?
>>> 
>>> As this operation involves certain computational overhead, it would be
>>> interesting to get some tests on older machines. Unfortunately all
>>> pc's that I have access to, are too fast.
>>> 
>>> This patch also fixes http://savannah.gnu.org/bugs/?31610 for the fltk 
>>> toolkit.
>>> 
>>> Finally, if we adopt the attached patch we have to adapt legend.m also.
>>> 
>>> BR
>>> 
>>> Kostas
>> 
>> After some more testing and fixes I think the patch is quite mature in
>> the form you find in the attachment. I think it could be checked in.
>> 
> I have just checked in this changeset along with some further
> fixes/improvements. Now, I would like to provide some additional
> information and ask for some help with regard to the open issues that I
> had listed.
> 
>> There are still some general issues with fltk that I will try to sum up:
>> 
>> 1. In some demo plots axes labels seem to be too close to the axes
>> (e.g. demo legend 9). Probably in some of the previous changes there
>> is something that I have overseen.
>> 
> Actually after testing older revisions of octave I realized that the
> problem is not new. The reason that I hadn't noticed it before is
> because the problem appears only in the print output and not in the plot
> window. It seems that gl-render and gl2ps position strings differently
> considering either the bottom line or the baseline of the string
> respectively. It is not difficult to fix, we just have to decide which
> of gl-render and gl2ps are we going to fix in order to make both
> consistent.

I suspect the culprit may be that gl2ps requires assumes that the DPI is 72.

Perhaps the font position is correct, but the fontsize is off by 100/72? But is 
that due to a bug in gl2ps or a problem with Octave's positioning of text 
objects?

>> 2. Legends for barplots don't show colors (this is an old problem).
>> 
>> 3. Some small y axes interference for plotyy (also not new).
>> 
>> 4. Now there is no labels-titles interference in demo subplot 1, so
>> there is no need for extra space between the subplots, we can reduce a
>> bit the padding (someone which is familiar with subplot.m I suppose).
>> 
> Waiting for someone familiar with subplot.m

I'll take a look.

>> 5. In demo axis 4, legends are not positioned correctly. I think the
>> position of the legend for these cases should rely exclusively on
>> position of the parent axes and not on outerposition, but I have not
>> tried to implement this. David could you take a look at legend.m?
>> 
> Waiting for someone familiar with legend.m

I experimented a bit. If the titles are removed the legends are placed 
correctly (they don't move, but the axis position does). I looks to me like the 
problem is on the c++ side. Haven't the axis position values already been 
updated to account for the title when the legend is called?

Ben