Re: Patches for autopositioning of labels in fltk

[Ben Abbott]

On Dec 9, 2010, at 6:02 PM, bpabbott wrote:

> 
>> On Thu, 2010-12-09 at 20:43 +0000, bpabbott wrote:
>> > On Dec 09, 2010, at 02:30 PM, logari81 <address@hidden>
>> > wrote:
>> > 
>> > 
>> > > > > 
>> > > > > 
>> > > > > The clipping property was the culprit for the disappearing
>> > > labels.
>> > > > > Please merge the attached changeset with the previous one and
>> > > you
>> > > > > should
>> > > > > receive a behavior for the fltk backend which is quite
>> > > compatible
>> > > > > with
>> > > > > ML.
>> > > > > 
>> > > > > There are still some smaller issues:
>> > > > > 
>> > > > > 1. When setting a label from a text handle, the fontsize of the
>> > > text
>> > > > > is
>> > > > > kept, like also in ML. The problem is that in Octave we have
>> > > > > different
>> > > > > default sizes for {xyz}label and text. Default fontsize for
>> > > labels
>> > > > > is
>> > > > > 12, while default fontsize for text is 10. This can cause a bit
>> > > of
>> > > > > confusion.
>> > > > 
>> > > > Matlab 2010b on MacOS X uses a fontsize of 10 for all text
>> > > objects.
>> > > > 
>> > > > 
>> > > > h = findall (0, '-property', 'fontsize');
>> > > > type = get (h, 'type');
>> > > > fsize = cellfun (@(t) get (0, sprintf ('default%sfontsize', t)),
>> > > type)
>> > > > 
>> > > > 
>> > > > fsize =
>> > > > 
>> > > > 
>> > > > 10
>> > > > 10
>> > > > 10
>> > > > 10
>> > > > 10
>> > > > 
>> > > > 
>> > > > Can you modify the default fontsize for for Octave objects so that
>> > > > they are consistent?
>> > > > 
>> > > > 
>> > > > .. or, If you prefer, I can do that later today.
>> > > > 
>> > > > 
>> > > > > 2. It seems that there are some inconsistencies with the z
>> > > position
>> > > > > coordinate of label and text objects but I haven't found a test
>> > > case
>> > > > > yet, where this causes problems. Anyway I think one should go
>> > > > > through
>> > > > > octave and just make sure that all default z coordinates for 2D
>> > > > > objects
>> > > > > are consistent with ML, just to avoid trouble in the future.
>> > > > 
>> > > > 
>> > > > It looks to me like the differing z-values are a results of
>> > > listeners.
>> > > > From Matlab, I see ...
>> > > > 
>> > > > 
>> > > > >> clf
>> > > > >> hx = xlabel ('xlabel')
>> > > > 
>> > > > 
>> > > > hx =
>> > > > 
>> > > > 
>> > > > 174.0015
>> > > > 
>> > > > 
>> > > > >> px = get (hx, 'position')
>> > > > 
>> > > > 
>> > > > px =
>> > > > 
>> > > > 
>> > > > 0.4988 -0.0658 1.0001
>> > > > 
>> > > > 
>> > > > >> get (gca, 'zlim')
>> > > > 
>> > > > 
>> > > > ans =
>> > > > 
>> > > > 
>> > > > 0 1
>> > > > 
>> > > > 
>> > > > >> zlim ([0, 2])
>> > > > >> px = get (hx, 'position')
>> > > > 
>> > > > 
>> > > > px =
>> > > > 
>> > > > 
>> > > > 0.4988 -0.0658 2.0001
>> > > > 
>> > > > 
>> > > > If I'm not missing something, the list below summarizes the
>> > > remaining
>> > > > issues.
>> > > > 
>> > > > 
>> > > > (1) Change all default font sizes to one consistent value (10?).
>> > > > 
>> > > The attached patch replaces any appearances of 12 in fontsizes with
>> > > 10.
>> > > It seems a bit too small for my taste but I vote for using the same
>> > > value as in ML (10).
>> > 
>> > 10 is ok with me. But feel free to use 12. There is no compelling
>> > reason to copy ML's default value.
>> > 
>> > > > 
>> > > > (2) when a text object's handle is assigned to the xlabel, ylabel,
>> > > > zlabel, or title properties, the text object's positionmode and
>> > > > rotationmode should be set to "auto".
>> > > This is done in my last patch (previous mail).
>> > > 
>> > > > This should place the text objects in their usual locations.
>> > > Meaning
>> > > > the default locations for xlabel, ylabel, zlabel, and title, which
>> > > is
>> > > > different than the default text object positon.
>> > > > 
>> > > This is done for the fltk backend also in my last patch. Do you
>> > > maybe
>> > > refer to the gnuplot backend? Anyway AFAIK gnuplot doesn't support
>> > > many
>> > > options for positioning and rotating the axes labels, so probably it
>> > > can't be 100% compatible. In my tests the gnuplot backend seems to
>> > > work
>> > > as reasonably as before my patches.
>> > 
>> > I've attached a test script and the three plots it produces for Octave
>> > (FLTK) and Matlab. Since my results no longer indicate cropping, I'm
>> > confident I have your patches applied correctly. Do you get something
>> > different?
>> > 
>> > 
>> > Regarding gnuplot, the method used to render xlabel, ylabel, zlabel,
>> > and the title can be changed to use normal text objects.
>> > 
>> > 
>> > > Some clarification about the current implementation in my last patch
>> > > (disable_label_autoposition_standalone_part2.changeset):
>> > > 
>> > > When an axis label is set to some other text object, the position,
>> > > rotation and alignment properties are set to auto mode and are
>> > > recalculated next time the axes are drawn. _But_, when a title
>> > > object is
>> > > set to some other text, the alignment properties are reverted to
>> > > their
>> > > default values, the position is set to auto mode and the rotation is
>> > > inherited from the text object. I don't know why but ML also handles
>> > > the
>> > > title differently than labels, so I tried to stick to the ML
>> > > behavior.
>> > > 
>> > > 
>> > > > 
>> > > > (3) listeners are needed to ensure the text objects associated
>> > > with
>> > > > the xlabel, ylabel, zlabel, or title axis properties are assigned
>> > > > values that place them above the other children of the axis.
>> > > > 
>> > > Sorry, this is something that I can't understand. Could you provide
>> > > some
>> > > more explanation?
>> > 
>> > It looks to me like the z-position for 2D plots changes as zlim
>> > changes. I'd guess that in 3D cases all labels may change so that they
>> > are a bit closer to the viewer than the other objects. Does that make
>> > sense?
>> > 
>> > 
>> > Ben
>> > 
>> > 
>> > 
>> > Octave-1.pngOctave-2.pngOctave-3.pngMATLAB-1.pngMATLAB-2.pngMATLAB-3.png
>> > 
>> 
>> running the script I also receive the error you have on your third plot
>> but my second plot is ok. When I make the plot in a window instead of a
>> png I get no errors at all.
>> 
>> I will try to see why the problem occurs only with png and come back
>> with more details.
>> 
>> Regards
>> 
>> Kostas
>  
> Ok. I get the same result in the FLTK window as is seen in the png file.
> 
> Another short test ...
> 
> clf
> ht = text (0.5, 0.5, "Hello World");
> set (gca, "xlabel", ht)
> get (ht, "positionmode")
> ans = manual
> get (ht, "position")
> ans =   0.50000   0.50000   0.00000
> 
> If I then force the position mode ...
> 
> set (hx, "positionmode", "auto")
> get (hx, "position")
> ans =   0.500000  -0.052598  -1.000000
> 
> ... which indicates the correct position.  I've occasionally had problems 
> with builds on MacOS X. I'll try the same using Ubuntu via VirtualBox and 
> report back later.
> 
> Ben

Your changes worked for me (as they do for you) on Ubuntu. After a fresh build 
and carefully apply the changes on MacOS X, they work there as well.

The problem with the third plot is that the x-position of the labels is set in 
a lazy fashion. It isn't set until after the script is done. If a "drawnow" is 
included after "hx = xlabel ('xlabel')", it works correctly.

clf
px = get (xlabel ('hello world'), 'position')
px =   0   0   0
drawnow
get (get (gca, "xlabel"), "position")
ans =   0.50000  -0.05260   0.00000

Running matlab I get  "0.4988   -0.0658    1.0001" both times.

Is this something that can be easily fixed, or should a bug report be added to 
the tracker?

Ben