octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Patches for autopositioning of labels in fltk


From: bpabbott
Subject: Re: Patches for autopositioning of labels in fltk
Date: Thu, 09 Dec 2010 23:02:19 +0000 (GMT)


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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]