Re: Patches for autopositioning of labels in fltk

[logari81]

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