octave-maintainers
[Top][All Lists]
Advanced

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

Re: about contibuting to octave


From: xianghang liu
Subject: Re: about contibuting to octave
Date: Fri, 6 Mar 2009 06:54:49 +0800



On Fri, Mar 6, 2009 at 6:53 AM, xianghang liu <address@hidden> wrote:


On Thu, Mar 5, 2009 at 8:21 PM, Shai Ayal <address@hidden> wrote:
On Thu, Mar 5, 2009 at 12:00 PM, xianghang liu <address@hidden> wrote:
>
>
> On Wed, Mar 4, 2009 at 9:14 PM, Ben Abbott <address@hidden> wrote:
>>
>> On Mar 4, 2009, at 5:09 AM, Michael Goffioul wrote:
>>
>>> On Wed, Mar 4, 2009 at 9:22 AM, xianghang liu <address@hidden>
>>> wrote:
>>>>
>>>> In freetype, I found two functions
>>>>
>>>> FT_Outline_Get_BBox Compute the exact bounding box of an outline.
>>>> FT_Outline_Get_CBox Return an outline's ‘control box’.
>>>>
>>>> After a rough glance at ftgl's bounding box computation, I think it use
>>>> FT_Outline_Get_CBox to compute the box of each glyph and add them
>>>> together
>>>> to get the extent of the string. Shall we just follow the same method?
>>>
>>> AFAIK, depending on the font, the width of a string is not the same as
>>> the sum of the width of all its characters. OTOH, I think you can assume
>>> that the width of a string will always be <= than the sum of the width of
>>> its characters. So adding the box of each glyph should give you a maximum
>>> width anyway.
>>>
>>> Note that I'm not a font expert, so I might be wrong.
>>>
>>> Michael.
>>
>> I'm uncertain about this as well. Does anyone following along know?
>>
>> I was under the impression that the spacing between characters depends
>> upon the neighboring characters (however, I might be thinking of LaTeX,
>> which I'd expect to have a more complicated scheme). If a string's extent is
>> not the sum of is character's extents, then we will require something to
>> calculate the extents of a string directly. Which is something that gdlib
>> and ftgl provide for.
>>
>> In any event, I'm thrilled that xianghang has taken on this effort. From
>> my perspective this represents the largest obstacle to improving the
>> compatibility of the gnuplot backend.
>>
>> Ben
>
> I found two methods to get the extent of text objects by freetype:
>
> use FT_Outline_Get_CBox to get the bounding box of a single glyph and
> FT_Get_Kerning to get the kerning vector between two glyphs. This is the
> method used in FTGL and contained in FTFontImpl::BBoxI.
> in gdft.c of gd library source code, there is a function gdImageStringFTEx
> and some similiar funcions. These functions implement another method to get
> bounding box from glyph metrics. These functions are what PHP function
> imagettfbbox use to get bounding box. Call to these functions can be found
> in PHP source code  \php-5.2.9\ext\gd\gd.c
>
>  Xianghang Liu
>
I would go with freetype2, since it seems to be the current standard
librbary for font handling, and we will be using it in the
opengl-renderer anyway

Shai



What I mean is the same as you: we compute extent of text objects with freetype2 and without any dependency on backends. What I mentioned in my last email is the how backends (FTGL and GD) use freetype2 to get extent.
I would like to implement these two methods and examine whether they get the same result.
Any suggestions?

 Xianghang Liu

reply via email to

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