-
-
-
-
-
-
- The purpose of this section is to present the way FreeType
-manages vectorial outlines, as well as the most common operations that
-can be applied on them.
-
-
-
-
-
-a. Outline curve decomposition :
-
-
-An outline is described as a series of closed contours in the
-2D plane. Each contour is made of a series of line segments and bezier
-arcs. Depending on the file format, these can be second-order or third-order
-polynomials. The former are also called quadratic or conic arcs, and they
-come from the TrueType format. The latter are called cubic arcs and mostly
-come from the Type1 format.
-
-
-Each arc is described through a series of start, end and control points.
-Each point of the outline has a specific tag which indicates wether it
-is used to describe a line segment or an arc. The tags can take the
-following values :
-
-
-
-
- FT_Curve_Tag_On
- |
-
-
- Used when the point is "on" the curve. This corresponds to
-start and end points of segments and arcs. The other tags specify what
-is called an "off" point, i.e. one which isn't located on the contour itself,
-but serves as a control point for a bezier arc.
- |
-
-
-
-
- FT_Curve_Tag_Conic
- |
-
-
- Used for an "off" point used to control a conic bezier arc.
- |
-
-
-
-
- FT_Curve_Tag_Cubic
- |
-
-
- Used for an "off" point used to control a cubic bezier arc.
- |
-
-
-
-
-The following rules are applied to decompose the contour's points into
-segments and arcs :
-
-
-
-- two successive "on" points indicate a line segment joining them.
-
-- one conic "off" point amidst two "on" points indicates a conic bezier
-arc, the "off" point being the control point, and the "on" ones the
-start and end points.
-
--
-Two successive cubic "off" points amidst two "on" points indicate a cubic
-bezier arc. There must be exactly two cubic control points and two on
-points for each cubic arc (using a single cubic "off" point between two
-"on" points is forbidden, for example).
-
-
--
-finally, two successive conic "off" points forces the rasterizer to create
-(during the scan-line conversion process exclusively) a virtual "on" point
-amidst them, at their exact middle. This greatly facilitates the definition
-of successive conic bezier arcs. Moreover, it's the way outlines are
-described in the TrueType specification.
-
-
-
- Note that it is possible to mix conic and cubic arcs in a single
-contour, even though no current font driver produces such outlines.
-
-
-
-
-
-
- |
-
-
-
- |
-
-
-
-
-
- |
-
-
-
- |
-
-
-
-
-b. Outline descriptor :
-
-A FreeType outline is described through a simple structure,
-called FT_Outline, which fields are :
-
-
-
-
- n_points
- |
-
-
- the number of points in the outline
- |
-
-
-
-
- n_contours
- |
-
-
- the number of contours in the outline
- |
-
-
-
-
- points
- |
-
-
- array of point coordinates
- |
-
-
-
-
- contours
- |
-
-
- array of contour end indices
- |
-
-
-
-
- tags
- |
-
-
- array of point flags
- |
-
-
-
-Here, points is a pointer to an array of
-FT_Vector records, used to store the vectorial coordinates of each
-outline point. These are expressed in 1/64th of a pixel, which is also
-known as the 26.6 fixed float format.
-
-
-contours is an array of point indices used to delimit
-contours in the outline. For example, the first contour always starts at
-point 0, and ends a point contours[0]. The second contour
-starts at point "contours[0]+1" and ends at
-contours[1], etc..
-
-
-Note that each contour is closed, and that n_points
-should be equal to "contours[n_contours-1]+1" for a valid
-outline.
-
-
-Finally, tags is an array of bytes, used to store each
-outline point's tag.
-
-
-
-
-
-A bounding box (also called "bbox") is simply
-the smallest possible rectangle that encloses the shape of a given outline.
-Because of the way arcs are defined, bezier control points are not
-necessarily contained within an outline's bounding box.
-
-
-This situation happens when one bezier arc is, for example, the upper
-edge of an outline and an off point happens to be above the bbox. However,
-it is very rare in the case of character outlines because most font designers
-and creation tools always place on points at the extrema of each curved
-edges, as it makes hinting much easier.
-
-
-We thus define the control box (a.k.a. the "cbox") as
-the smallest possible rectangle that encloses all points of a given outline
-(including its off points). Clearly, it always includes the bbox, and equates
-it in most cases.
-
-
-Unlike the bbox, the cbox is also much faster to compute.
-
-
-
- |
-
- |
-
-
-
-Control and bounding boxes can be computed automatically through the
-functions FT_Get_Outline_CBox and FT_Get_Outline_BBox.
-The former function is always very fast, while the latter may be
-slow in the case of "outside" control points (as it needs to find the extreme
-of conic and cubic arcs for "perfect" computations). If this isn't the
-case, it's as fast as computing the control box.
- Note also that even though most glyph outlines have equal cbox and bbox
-to ease hinting, this is not necessary the case anymore when a
-transform like rotation is applied to them.
-
-
-
-
-An outline point's vectorial coordinates are expressed in the
-26.6 format, i.e. in 1/64th of a pixel, hence coordinates (1.0, -2.5) is
-stored as the integer pair ( x:64, y: -192 ).
-
-
-After a master glyph outline is scaled from the EM grid to the current
-character dimensions, the hinter or grid-fitter is in charge of aligning
-important outline points (mainly edge delimiters) to the pixel grid. Even
-though this process is much too complex to be described in a few lines,
-its purpose is mainly to round point positions, while trying to preserve
-important properties like widths, stems, etc..
-
-
-The following operations can be used to round vectorial distances in
-the 26.6 format to the grid :
-
+
+ FreeType Glyph Conventions
+
+
+
+ Version 2.1
+
+
+
+ Copyright 1998-2000 David Turner (david@freetype.org)
+ Copyright 2000 The FreeType Development Team (devel@freetype.org)
+
-round(x) == (x+32) & -64
- floor(x) == x &
--64
- ceiling(x) == (x+63) & -64
-
-Once a glyph outline is grid-fitted or transformed, it often is interesting
-to compute the glyph image's pixel dimensions before rendering it. To do
-so, one has to consider the following :
- The scan-line converter draws all the pixels whose centers fall
-inside the glyph shape. It can also detect "drop-outs", i.e.
-discontinuities coming from extremely thin shape fragments, in order to
-draw the "missing" pixels. These new pixels are always located at a distance
-less than half of a pixel but one cannot predict easily where they'll appear
-before rendering.
- This leads to the following computations :
-
-
-
-
--
-grid-fit the bounding box with the following :
-
-
-
- xmin = floor( bbox.xMin )
- xmax = ceiling( bbox.xMax )
- ymin = floor( bbox.yMin )
- ymax = ceiling( bbox.yMax )
-
-
--
-return pixel dimensions, i.e.
-width = (xmax - xmin)/64 and height = (ymax - ymin)/64
-
-
-
- By grid-fitting the bounding box, one guarantees that all the pixel
-centers that are to be drawn, including those coming from drop-out
-control, will be within the adjusted box. Then the
-box's dimensions in pixels can be computed.
-
Note also that, when translating a grid-fitted outline,
-one should always use integer distances to
-move an outline in the 2D plane. Otherwise, glyph edges won't be aligned
-on the pixel grid anymore, and the hinter's work will be lost, producing
-very
-low quality bitmaps and pixmaps..
-
-
-
-
- |