[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Improvements in the calculation of text extents
From: |
Ben Abbott |
Subject: |
Re: Improvements in the calculation of text extents |
Date: |
Thu, 23 Dec 2010 21:53:44 -0500 |
On Dec 22, 2010, at 6:43 AM, logari81 wrote:
> Currently, the calculation of the extent of text objects in Octave is
> very limited. For example it doesn't take into account the rotation
> angle:
>
> Revision 11407 of Octave:
>
> octave:1> backend fltk
> octave:2> hx = xlabel('x label');
> octave:3> get (hx, 'extent')
> ans =
> 1.6832e-17 -7.7629e-17 6.2500e-02 3.6252e-02
> octave:4> set(hx, 'rotation', 90)
> octave:5> get (hx, 'extent')
> ans =
> 1.6832e-17 -7.7629e-17 2.6210e-02 8.6447e-02
>
> For this reason I have worked in cleaning up and improving the
> calculation of text extents and positioning of text. My modifications
> can be found in the attached changeset. The result of the previous
> example after these changes becomes rotation aware:
>
> With the attached changeset:
>
> octave:1> backend fltk
> octave:2> hx = xlabel('x label');
> octave:3> get (hx, 'extent')
> ans =
> -0.033266 -0.039041 0.062500 0.036252
> octave:4> set(hx, 'rotation', 90)
> octave:5> get (hx, 'extent')
> ans =
> -0.0020161 -0.0460123 0.0262097 0.0864473
>
> For comparison see the corresponding result from ML:
>
>>> hx = xlabel('x label');
>>> get (hx,'extent')
> ans =
> 0.4458 -0.1115 0.0982 0.0541
>>> set (hx, 'rotation', 90)
>>> get (hx,'extent')
> ans =
> 0.4761 -0.1521 0.0605 0.1521
>
> The attached patch does not only fix this small problem but also
> prepares all necessary infrastructure for handling the tightinset
> property later.
>
> The first two components of the extent property implemented in the
> attached changeset are not compatible with ML. The convention that ML
> uses for these two components makes sense only in 2D plots and I don't
> think that it is good idea to follow the ML convention in this case.
>
> Please test the attached patch and give me some feedback in case it
> breaks anything. Otherwise I think it is a good idea to commit it since
> it cleans up a few things.
>
> BR
>
> Kostas
> <text-extents.changeset>
This changeset doesn't apply for me. In particular, some lines from graphics.cc
seem to be different than what is indicated by your changeset.
The current sources indicate ...
5079 elt = text_parser_none ().parse (get_string ());
5080 #ifdef HAVE_FONTCONFIG
5081 text_renderer.set_font (*this);
5082 #endif
5083 box = text_renderer.get_extent (elt, get_rotation ());
... but your changeset expects ...
- elt = text_parser_none ().parse (get_string ());
-#ifdef HAVE_FONTCONFIG
- text_renderer.set_font (get ("fontname").string_value (),
- get ("fontweight").string_value (),
- get ("fontangle").string_value (),
- get ("fontsize").double_value ());
-#endif
- box = text_renderer.get_extent (elt, get_rotation ());
Ben
- Improvements in the calculation of text extents, logari81, 2010/12/22
- Re: Improvements in the calculation of text extents,
Ben Abbott <=
- Re: Improvements in the calculation of text extents, Jordi GutiƩrrez Hermoso, 2010/12/24
- Re: Improvements in the calculation of text extents, Konstantinos Poulios, 2010/12/26
- Re: Improvements in the calculation of text extents, Konstantinos Poulios, 2010/12/26
- Re: Improvements in the calculation of text extents, Ben Abbott, 2010/12/27
- Re: Improvements in the calculation of text extents, Konstantinos Poulios, 2010/12/28
- Re: Improvements in the calculation of text extents, bpabbott, 2010/12/28
- Re: Improvements in the calculation of text extents, bpabbott, 2010/12/28
- Re: Improvements in the calculation of text extents, Konstantinos Poulios, 2010/12/29
- Re: Improvements in the calculation of text extents, bpabbott, 2010/12/29