Re: [ft-devel] Strange behavior of freetype2 function FT_Outline_Decompose()
1) FT_Outline_Decompose() does not walk through all the Outline
contour-points one-by-one and call the emitters.
By printing out the to_points passed to the emitters by
FT_Outline_Decompose(), we noticed that there are gaps. The
decomposition begins with a consecutive sequence followed with
sequences of skipping by one point or more. There isn't any obvious
correlation with the type of corresponding emitters (line_to(),
conic_to() or cubic_to())
This is rather easy to explain: TrueType allows that on-curve spline
points can be omitted under certain assumptions. In the attached
image, there are on-curve points between points 9 and 10 and points 20
and 21.
Consider this example, taken from the letter `m' in FreeMono.ttf,
version 1.126:
point coordinates flag
--
0 (129,576)on
1 (129,497)on
2 (157,540)off
- unnumbered on-curve point in the middle
between points 2 and 3
3 (212,576)off
4 (248,576)on
5 (320,576)off
6 (372,491)on
7 (435,576)off
8 (501,576)on
9 (551,576)off
- unnumbered on-curve point in the middle
between points 9 and 10
10 (641,492)off
11 (641,434)on
Note that I've used
#define CHAR_WIDTH_DEFAULT_SIZE 20*64
#define CHAR_HEIGHT_DEFAULT_SIZE 20*64
in outline_decompose.c to get a reasonable glyph size of 20ppem --
1ppem, as used in your example, is too small, even for testing
purposes.
Using the above table, it is rather easy to see that the following
points are passed to the various callback functions:
callback `to' point
---
move_to 0
line_to 1
conic_tocomputed
conic_to4
conic_to6
conic_to8
conic_tocomputed
conic_to 11
2) When closing the decomposition of a contour, the coordinates of the
to_point passed to the emitter is not transformed.
Well, this is your own fault :-) Look at your function
is_a_contour_end_point:
int
is_a_contour_end_point(FT_Outline outline,
FT_Vector* to,
FT_Pos delta,
int shift)
{
...
to-x = (to-x + delta) shift;
to-y = (to-y + delta) shift;
...
}
In other words, you modify the `to' vector, and you shouldn't do this.
Everything's fine if you copy the `to' vector locally before
transforming it back.
BTW, this error would have been easily detected if you had strictly
followed the definitions in ftimage.h. For example, the function
signature of the `move to' emitter is
typedef int
(*FT_Outline_MoveToFunc)( const FT_Vector* to,
void* user );
while you declare it as
int
move_to( FT_Vector* to,
void* payload )
which drops the `const' qualifier.
3) We also observed that most decomposition ended with a call to an
emitter from the end-point of a contour to its first-point
(to_point) to close the decomposition. Occasionally, we will see a
decomposition ending with a call to an emitter (usually a line_to(),
sometime a conic_to()) not from the last point of the contour, but
from the contour-point before the last one, to the first point of
that contour.
This is the same `problem' as issue 1 because of unnumbered on-curve
points.
Werner
inline: ttf-spline.png___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Re: About the Advance value.
In the FtViewer, after the function “FTC_ImageCache_LookupScaler” was call, I can get the two value: dXAdvance = (glyph-advance.x) 16; dYAdvance = (glyph-advance.y) 16; And what I want to know is how to get the values without calling the function “FTC_ImageCache_LookupScaler”. Look into ftdiff.c to see a real usage of `advance.x'. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
RE: 答复: [ft-devel] porting the freetyp e tosymbian S60 3Rd
Oh dear - I shouldn't have said anything - sorry, I have no time to deal
with this. All I can say is that if there was a memory leak in FreeType it
would show up in all sorts of places - not just in Symbian OS. I suspect
it's a problem in the calling code.
I recently had heap corruption problems, added huge amounts of
instrumentation to the app I was working on, and found nothing wrong in
FreeType. The bug turned out to be in my own code, as usual.
Graham
-Original Message-
From: freetype-devel-bounces+graham.asher=btinternet@nongnu.org
[mailto:freetype-devel-bounces+graham.asher=btinternet@nongnu.org] On
Behalf Of Werner LEMBERG
Sent: 16 December 2008 17:54
To: hie...@hotmail.com
Cc: freetype-devel@nongnu.org
Subject: Re: 答复: [ft-devel] porting the freetype tosymbian S60 3Rd
Src/base/ftsystem.c
FT_CALLBACK_DEF( void* )
ft_alloc( FT_Memory memory,
long size )
{
FT_UNUSED( memory );
return ft_smalloc( size );// memory leak
}
You can have a look at the attached jepg for more information.
Thanks. I've forwarded your message to Graham since he has most
experience with Symbian.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] porting the freetype to symbian S60 3Rd
Hi ALL, First, It is a great open source projectJ I am Hong Li, from china. Actually I have already ported freetype to symbian but I saw memory leak in your code. you use malloc and free which don't work well on symbian.I use the hook Logger tool to confirm that there is memory leak.. Do anyone have any comments? Your realy reply is highly appreciated. Hong Li from China,Bei Jing ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] porting the freetype to symbian S60 3Rd
First, It is a great open source projectJ I am Hong Li, from china. Actually I have already ported freetype to symbian but I saw memory leak in your code. you use malloc and free which don't work well on symbian. I use the hook Logger tool to confirm that there is memory leak.. Interesting. Please give more details. However, you should use the current CVS code of the FreeType library; maybe your problem has been fixed meanwhile. Note that FreeType itself comes with a memory debugger; please read the file docs/DEBUG for more. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
