[ft-devel] Strange behavior of freetype2 function FT_Outline_Decompose()

[Chi Nguyen]

To freetype maintainers,

In developing the test for the freetype2 function FT_Outline_Decompose() we
have detected a few strange behaviors.
These anomalies were observed on our 32 and 64 bit, Intel based test
systems. The distros used on these tests systems include RHEL52 x86 64, SLES
10.1 x86 32, OpenSUSE11 x86 32 and Fedora9 x86 32. 

We have discovered the following peculiarities of the function
FT_Outline_Decompose() that we would like to bring to your attention:

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())

2) When closing the decomposition of a contour, the coordinates of the
to_point passed to the emitter is not transformed.
For example in the case of "m":

>>>>>>>>>>>>>>>
Decomposing the outline of the character m of the font ./fonts/FreeMono.ttf

Number of paths started is 1, number of paths ended is 1 Number of contours
in the decomposed outline: 1.

The function did emit a 'move_to' operation.

The decomposition did close the outline.

>>>>>>>>>>>>>>>

Where the last 5 points of this outline are:

>>>>>>

The number of points in this outline is 63.

Outline point 0 is (7,64)
Outline point 1 is (7,56)
Outline point 2 is (10,63)
...
...
...
Outline point 58 is (2,58)
Outline point 59 is (1,58)
Outline point 60 is (1,61)
Outline point 61 is (1,64)
Outline point 62 is (2,64)

Outline end-of-contour points are: 62
>>>>>>

The trace of the last four scans is as follows:

>>>>>>>>>>>>

Entering line_to().
Input point is (2043,59387)
Transformed back input point is (2,58)
Starting to scan from 58.
To point index is 58.
Index of to_point is 58, contour end-point is 62

Entering conic_to().
Input point is (1019,62459)
Transformed back input point is (1,61)
Starting to scan from 59.
To point index is 60.
Index of to_point is 60, contour end-point is 62

Entering conic_to().
Input point is (2043,65531)
Transformed back input point is (2,64)
Starting to scan from 61.
To point index is 62.
Index of to_point is 62, contour end-point is 62 
Path ended inside conic_to().

Entering line_to().
Input point is (7,64)
Transformed back input point is (0,0)
Starting to scan from 0.
To point index is 0.
Index of to_point is 0, contour end-point is 62


>>>>>>>>>>>>

The coordinates of the first contour-point, passed to the emitter to close
the decomposition, was not run through the SCALED transformation.

In the example above, the coordinates of the first-point (7,64), passed to
the emitter line_to() to close the decomposition, was not run through the
SCALED transformation.
Therefore the reverse transform applied to it, yielded (0,0). Although in
this case, the closing of this decomposition not was missed by our test,
should it be this way?

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. 
Therefore, since, FT_Outline_Decompose() skipped over the end-point of the
contour, our test concluded that it did not close the decomposition of the
character under test. 
For example, this behavior happened in the decomposition of "O" and "s".



Included with this email is a C test program outline_decompose.c that we
used to help illustrate the problems. We have reproduced these problems with
OpenSuSE 11 (32 bit), Ubuntu 8.04 (ia32), RHEL52 x86-64, SLES 10.1 (32bit),
Fedora 9 (32bit) with freetype 2.3.7.

Thanks for your attention and please do contact us if you need any further
detail.

We appreciate any ruling or clarification that you may have.


Sincerely yours,





Nguyen Trung Chi
NEC Solutions VietNam (NECSV)

address@hidden

outline_decompose.c
Description: Text document