2000-06-16 21:34:52 +02:00
|
|
|
LATEST CHANGES
|
|
|
|
|
2000-10-28 19:10:06 +02:00
|
|
|
- "type1z" renamed back to "type1"; the old "type1" module has been
|
|
|
|
removed
|
|
|
|
|
2000-09-16 00:42:06 +02:00
|
|
|
- revamped the build system to make it a lot more generic. This will
|
|
|
|
allow us to re-use nearly un-modified in lots of other projects
|
|
|
|
(including FreeType Layout)
|
|
|
|
|
2000-08-24 00:47:44 +02:00
|
|
|
- changed "cid" to use "psaux" too..
|
|
|
|
|
2000-08-23 23:11:13 +02:00
|
|
|
- added the cache sub-system. See <freetype/ftcache.h> as well as the
|
|
|
|
sources in "src/cache". Note that it compiles but is still untested
|
|
|
|
for now ..
|
|
|
|
|
2000-08-23 04:47:57 +02:00
|
|
|
- updated "docs/docmaker.py", a draft API reference is available at
|
|
|
|
http://www.freetype.org/ft2api.html
|
|
|
|
|
2000-10-28 19:10:06 +02:00
|
|
|
- changed "type1" to use "psaux"
|
2000-08-23 04:47:57 +02:00
|
|
|
|
|
|
|
- created a new module named "psaux" to hold the Type 1 & Type 2 parsing
|
2000-10-28 19:10:06 +02:00
|
|
|
routines. It should be used by "type1", "cid" and "cff" in the future
|
2000-08-23 04:47:57 +02:00
|
|
|
|
|
|
|
- fixed an important bug in "FT_Glyph_Get_CBox"
|
|
|
|
|
2000-07-27 23:48:48 +02:00
|
|
|
- fixed some compiler warnings that happened since the TrueType
|
|
|
|
bytecode decoder was deactivated by default..
|
|
|
|
|
2000-07-27 23:40:22 +02:00
|
|
|
- fixed two memory leaks:
|
|
|
|
- the memory manager (16 bytes) isn't released in FT_Done_FreeType !!
|
2000-10-31 21:42:18 +01:00
|
|
|
|
2000-07-27 23:40:22 +02:00
|
|
|
- using custom input streams, the copy of the original stream
|
|
|
|
was never released
|
|
|
|
|
|
|
|
- fixed the auto-hinter by performing automatic computation of the
|
|
|
|
"filling direction" of each glyph. This is done through a simple and
|
|
|
|
fast approximation, and seems to work (problems spotted by Werner
|
|
|
|
though). The Arphic fonts are a lot nicer though there are still a
|
|
|
|
lot of things to do to handle Asian fonts correctly..
|
|
|
|
|
|
|
|
===========================================================================
|
|
|
|
BETA-8 (RELEASE CANDIDATE) CHANGES
|
|
|
|
|
2000-07-26 21:13:51 +02:00
|
|
|
- deactivated the trueType bytecode interpreter by default
|
2000-10-31 21:42:18 +01:00
|
|
|
|
2000-07-26 21:13:51 +02:00
|
|
|
- deactivated the "src/type1" font driver. Now "src/type1z" is
|
|
|
|
used by default..
|
|
|
|
|
2000-07-26 21:04:08 +02:00
|
|
|
- updates to the build system. We now compile the library correctly
|
|
|
|
under Unix system through "configure" which is automatically called
|
|
|
|
on the first "make" invocation.
|
2000-10-31 21:42:18 +01:00
|
|
|
|
2000-07-26 21:04:08 +02:00
|
|
|
- added the auto-hinting module !!. Fixing some bugs here and there..
|
|
|
|
|
2000-07-12 18:57:37 +02:00
|
|
|
- found some bugs in the composite loader (seac) of the Type1-based
|
|
|
|
font drivers..
|
|
|
|
|
|
|
|
- renamed the directory "freetype2/config" to "freetype2/builds" and
|
2000-07-08 02:49:43 +02:00
|
|
|
updated all relevant files..
|
|
|
|
|
2000-07-07 21:47:34 +02:00
|
|
|
- found a memory leak in the "type1" driver
|
2000-10-31 21:42:18 +01:00
|
|
|
|
2000-07-07 21:47:34 +02:00
|
|
|
- incorporated Tom's patches to support flex operators correctly
|
|
|
|
in OpenType/CFF fonts.. Now all I need is to support pure CFF
|
|
|
|
and CEF fonts to be done with this driver.. :-)
|
|
|
|
|
|
|
|
- added the Windows FNT/FON driver in "src/winfonts". For now,
|
|
|
|
it always "simulates" a Unicode charmap, so it shouldn't be
|
|
|
|
considered completed right now..
|
2000-10-31 21:42:18 +01:00
|
|
|
|
2000-07-07 21:47:34 +02:00
|
|
|
It's there to be more a proof of concept than anything else
|
|
|
|
anyway. The driver is a single C source file, that compiles
|
|
|
|
to 3 Kb of code..
|
2000-10-31 21:42:18 +01:00
|
|
|
|
2000-07-07 21:47:34 +02:00
|
|
|
I'm still working on the PCF/BDF drivers.. but I'm too lazy
|
|
|
|
to finish them now..
|
|
|
|
|
|
|
|
|
2000-07-01 01:38:23 +02:00
|
|
|
- CHANGES TO THE HIGH-LEVEL API
|
2000-10-31 21:42:18 +01:00
|
|
|
|
2000-07-01 01:38:23 +02:00
|
|
|
o FT_Get_Kerning has a new parameter that allows you to select
|
|
|
|
the coordinates of the kerning vector ( font units, scaled,
|
|
|
|
scaled + grid-fitted ).
|
2000-10-31 21:42:18 +01:00
|
|
|
|
2000-07-01 01:38:23 +02:00
|
|
|
o the outline functions are now in <freetype/ftoutln.h> and not
|
|
|
|
part of <freetype/freetype.h> anymore
|
2000-10-31 21:42:18 +01:00
|
|
|
|
2000-07-01 01:38:23 +02:00
|
|
|
o <freetype/ftmodule.h> now contains declarations for
|
|
|
|
FT_New_Library, FT_Done_Library, FT_Add_Default_Modules
|
|
|
|
|
|
|
|
o the so-called convenience functions have moved from "ftoutln.c"
|
|
|
|
to "ftglyph.c", and are thus available with this optional component
|
|
|
|
of the library. They are declared in <freetype/ftglyph.h> now..
|
|
|
|
|
|
|
|
o anti-aliased rendering is now the default for FT_Render_Glyph
|
|
|
|
(i.e. corresponds to render_mode == 0 == ft_render_mode_normal).
|
|
|
|
To generate a monochrome bitmap, use ft_render_mode_mono, or the
|
|
|
|
FT_LOAD_MONOCHROME flag in FT_Load_Glyph/FT_Load_Char.
|
2000-10-31 21:42:18 +01:00
|
|
|
|
2000-07-01 01:38:23 +02:00
|
|
|
FT_LOAD_ANTI_ALIAS is still defined, but values to 0.
|
2000-10-31 21:42:18 +01:00
|
|
|
|
2000-07-01 01:38:23 +02:00
|
|
|
o <freetype/freetype.h> now include <freetype/config/ftconfig.h>,
|
|
|
|
solving a few headaches :-)
|
|
|
|
|
|
|
|
o the type FT_GlyphSlotRec has now a "library" field.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- CHANGES TO THE "ftglyph.h" API
|
2000-10-31 21:42:18 +01:00
|
|
|
|
2000-07-01 01:38:23 +02:00
|
|
|
This API has been severely modified in order to make it simpler,
|
|
|
|
clearer, and more efficient. It certainly now looks like a real
|
|
|
|
"glyph factory" object, and allows client applications to manage
|
|
|
|
(i.e. transform, bbox and render) glyph images without ever knowing
|
|
|
|
their original format.
|
|
|
|
|
2000-06-28 22:43:07 +02:00
|
|
|
- added support for CID-keyed fonts to the CFF driver.
|
|
|
|
maybe support for pure CFF + CEF fonts should come in ??
|
2000-06-28 01:32:27 +02:00
|
|
|
|
|
|
|
|
|
|
|
- cleaned up source code in order to avoid two functions with the
|
|
|
|
same name. Also changed the names of the files in "type1z" from
|
|
|
|
"t1XXXX" to "z1XXXX" in order to avoid any conflicts.
|
2000-10-31 21:42:18 +01:00
|
|
|
|
2000-06-28 01:32:27 +02:00
|
|
|
"make multi" now works well :-)
|
2000-10-31 21:42:18 +01:00
|
|
|
|
2000-06-28 06:19:49 +02:00
|
|
|
Also removed the use of "cidafm" for now, even if the source files
|
|
|
|
are still there. This functionality will certainly go into a specific
|
|
|
|
module..
|
2000-07-01 01:38:23 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
2000-10-31 21:42:18 +01:00
|
|
|
- ADDED SUPPORT FOR THE AUTO-HINTER
|
|
|
|
|
2000-07-01 01:38:23 +02:00
|
|
|
It works :-) I have a demo program which simply is a copy of "ftview"
|
|
|
|
that does a FT_Add_Module( library, &autohinter_module_class ) after
|
|
|
|
library initialisation, and Type 1 & OpenType/CFF fonts are now hinted.
|
2000-10-31 21:42:18 +01:00
|
|
|
|
2000-07-01 01:38:23 +02:00
|
|
|
CID fonts are not hinted, as they include no charmap and the auto-hinter
|
|
|
|
doesn't include "generic" global metrics computations yet..
|
2000-10-31 21:42:18 +01:00
|
|
|
|
2000-07-01 01:38:23 +02:00
|
|
|
Now, I need to release this thing to the FreeType 2 source..
|
|
|
|
|
|
|
|
|
2000-10-31 21:42:18 +01:00
|
|
|
|
|
|
|
|
2000-06-28 01:32:27 +02:00
|
|
|
|
|
|
|
- CHANGES TO THE RENDERER MODULES
|
2000-10-31 21:42:18 +01:00
|
|
|
|
2000-06-28 01:32:27 +02:00
|
|
|
the monochrome and smooth renderers are now in two distinct directories,
|
|
|
|
namely "src/raster1" and "src/smooth". Note that the old "src/renderer"
|
|
|
|
is now gone..
|
2000-10-31 21:42:18 +01:00
|
|
|
|
2000-06-28 01:32:27 +02:00
|
|
|
I ditched the 5-gray-levels renderers. Basically, it involved a simple
|
|
|
|
#define toggle in 'src/raster1/ftraster.c'
|
2000-10-31 21:42:18 +01:00
|
|
|
|
2000-06-28 01:32:27 +02:00
|
|
|
FT_Render_Glyph, FT_Outline_Render & FT_Outline_Get_Bitmap now select
|
|
|
|
the best renderer available, depending on render mode. If the current
|
|
|
|
renderer for a given glyph image format isn't capable of supporting
|
|
|
|
the render mode, another one will be found in the library's list.
|
2000-10-31 21:42:18 +01:00
|
|
|
|
2000-06-28 01:32:27 +02:00
|
|
|
This means that client applications do not need to switch or set the
|
|
|
|
renderers themselves (as in the latest change), they'll get what they
|
|
|
|
want automatically... At last..
|
2000-10-31 21:42:18 +01:00
|
|
|
|
2000-06-28 01:32:27 +02:00
|
|
|
Changed the demo programs accordingly..
|
2000-10-31 21:42:18 +01:00
|
|
|
|
|
|
|
|
2000-06-28 01:32:27 +02:00
|
|
|
|
- MAJOR INTERNAL REDESIGN:
A lot of internal modifications have been performed lately on the
source in order to provide the following enhancements:
- more generic module support:
The FT_Module type is now defined to represent a handle to a given
module. The file <freetype/ftmodule.h> contains the FT_Module_Class
definition, as well as the module-loading public API
The FT_Driver type is still defined, and still represents a pointer
to a font driver. Note that FT_Add_Driver is replaced by FT_Add_Module,
FT_Get_Driver by FT_Get_Module, etc..
- support for generic glyph image types:
The FT_Renderer type is a pointer to a module used to perform various
operations on glyph image.
Each renderer is capable of handling images in a single format
(e.g. ft_glyph_format_outline). Its functions are used to:
- transform an glyph image
- render a glyph image into a bitmap
- return the control box (dimensions) of a given glyph image
The scan converters "ftraster.c" and "ftgrays.c" have been moved
to the new directory "src/renderer", and are used to provide two
default renderer modules.
One corresponds to the "standard" scan-converter, the other to the
"smooth" one.
The current renderer can be set through the new function
FT_Set_Renderer.
The old raster-related function FT_Set_Raster, FT_Get_Raster and
FT_Set_Raster_Mode have now disappeared, in favor of the new:
FT_Get_Renderer
FT_Set_Renderer
see the file <freetype/ftrender.h> for more details..
These changes were necessary to properly support different scalable
formats in the future, like bi-color glyphs, etc..
- glyph loader object:
A new internal object, called a 'glyph loader' has been introduced
in the base layer. It is used by all scalable format font drivers
to load glyphs and composites.
This object has been created to reduce the code size of each driver,
as each one of them basically re-implemented its functionality.
See <freetype/internal/ftobjs.h> and the FT_GlyphLoader type for
more information..
- FT_GlyphSlot had new fields:
In order to support extended features (see below), the FT_GlyphSlot
structure has a few new fields:
linearHoriAdvance: this field gives the linearly scaled (i.e.
scaled but unhinted) advance width for the glyph,
expressed as a 16.16 fixed pixel value. This
is useful to perform WYSIWYG text.
linearVertAdvance: this field gives the linearly scaled advance
height for the glyph (relevant in vertical glyph
layouts only). This is useful to perform
WYSIWYG text.
Note that the two above field replace the removed "metrics2" field
in the glyph slot.
advance: this field is a vector that gives the transformed
advance for the glyph. By default, it corresponds
to the advance width, unless FT_LOAD_VERTICAL_LAYOUT
was specified when calling FT_Load_Glyph or FT_Load_Char
bitmap_left: this field gives the distance in integer pixels from
the current pen position to the left-most pixel of
a glyph image WHEN IT IS A BITMAP. It is only valid
when the "format" field is set to
"ft_glyph_format_bitmap", for example, after calling
the new function FT_Render_Glyph.
bitmap_top: this field gives the distance in integer pixels from
the current pen position (located on the baseline) to
the top-most pixel of the glyph image WHEN IT IS A
BITMAP. Positive values correspond to upwards Y.
loader: this is a new private field for the glyph slot. Client
applications should not touch it..
- support for transforms and direct rendering in FT_Load_Glyph:
Most of the functionality found in <freetype/ftglyph.h> has been
moved to the core library. Hence, the following:
- a transform can be specified for a face through FT_Set_Transform.
this transform is applied by FT_Load_Glyph to scalable glyph images
(i.e. NOT TO BITMAPS) before the function returns, unless the
bit flag FT_LOAD_IGNORE_TRANSFORM was set in the load flags..
- once a glyph image has been loaded, it can be directly converted to
a bitmap by using the new FT_Render_Glyph function. Note that this
function takes the glyph image from the glyph slot, and converts
it to a bitmap whose properties are returned in "face.glyph.bitmap",
"face.glyph.bitmap_left" and "face.glyph.bitmap_top". The original
native image might be lost after the conversion.
- when using the new bit flag FT_LOAD_RENDER, the FT_Load_Glyph
and FT_Load_Char functions will call FT_Render_Glyph automatically
when needed.
2000-06-22 02:17:42 +02:00
|
|
|
- MAJOR INTERNAL REDESIGN:
|
2000-10-31 21:42:18 +01:00
|
|
|
|
- MAJOR INTERNAL REDESIGN:
A lot of internal modifications have been performed lately on the
source in order to provide the following enhancements:
- more generic module support:
The FT_Module type is now defined to represent a handle to a given
module. The file <freetype/ftmodule.h> contains the FT_Module_Class
definition, as well as the module-loading public API
The FT_Driver type is still defined, and still represents a pointer
to a font driver. Note that FT_Add_Driver is replaced by FT_Add_Module,
FT_Get_Driver by FT_Get_Module, etc..
- support for generic glyph image types:
The FT_Renderer type is a pointer to a module used to perform various
operations on glyph image.
Each renderer is capable of handling images in a single format
(e.g. ft_glyph_format_outline). Its functions are used to:
- transform an glyph image
- render a glyph image into a bitmap
- return the control box (dimensions) of a given glyph image
The scan converters "ftraster.c" and "ftgrays.c" have been moved
to the new directory "src/renderer", and are used to provide two
default renderer modules.
One corresponds to the "standard" scan-converter, the other to the
"smooth" one.
The current renderer can be set through the new function
FT_Set_Renderer.
The old raster-related function FT_Set_Raster, FT_Get_Raster and
FT_Set_Raster_Mode have now disappeared, in favor of the new:
FT_Get_Renderer
FT_Set_Renderer
see the file <freetype/ftrender.h> for more details..
These changes were necessary to properly support different scalable
formats in the future, like bi-color glyphs, etc..
- glyph loader object:
A new internal object, called a 'glyph loader' has been introduced
in the base layer. It is used by all scalable format font drivers
to load glyphs and composites.
This object has been created to reduce the code size of each driver,
as each one of them basically re-implemented its functionality.
See <freetype/internal/ftobjs.h> and the FT_GlyphLoader type for
more information..
- FT_GlyphSlot had new fields:
In order to support extended features (see below), the FT_GlyphSlot
structure has a few new fields:
linearHoriAdvance: this field gives the linearly scaled (i.e.
scaled but unhinted) advance width for the glyph,
expressed as a 16.16 fixed pixel value. This
is useful to perform WYSIWYG text.
linearVertAdvance: this field gives the linearly scaled advance
height for the glyph (relevant in vertical glyph
layouts only). This is useful to perform
WYSIWYG text.
Note that the two above field replace the removed "metrics2" field
in the glyph slot.
advance: this field is a vector that gives the transformed
advance for the glyph. By default, it corresponds
to the advance width, unless FT_LOAD_VERTICAL_LAYOUT
was specified when calling FT_Load_Glyph or FT_Load_Char
bitmap_left: this field gives the distance in integer pixels from
the current pen position to the left-most pixel of
a glyph image WHEN IT IS A BITMAP. It is only valid
when the "format" field is set to
"ft_glyph_format_bitmap", for example, after calling
the new function FT_Render_Glyph.
bitmap_top: this field gives the distance in integer pixels from
the current pen position (located on the baseline) to
the top-most pixel of the glyph image WHEN IT IS A
BITMAP. Positive values correspond to upwards Y.
loader: this is a new private field for the glyph slot. Client
applications should not touch it..
- support for transforms and direct rendering in FT_Load_Glyph:
Most of the functionality found in <freetype/ftglyph.h> has been
moved to the core library. Hence, the following:
- a transform can be specified for a face through FT_Set_Transform.
this transform is applied by FT_Load_Glyph to scalable glyph images
(i.e. NOT TO BITMAPS) before the function returns, unless the
bit flag FT_LOAD_IGNORE_TRANSFORM was set in the load flags..
- once a glyph image has been loaded, it can be directly converted to
a bitmap by using the new FT_Render_Glyph function. Note that this
function takes the glyph image from the glyph slot, and converts
it to a bitmap whose properties are returned in "face.glyph.bitmap",
"face.glyph.bitmap_left" and "face.glyph.bitmap_top". The original
native image might be lost after the conversion.
- when using the new bit flag FT_LOAD_RENDER, the FT_Load_Glyph
and FT_Load_Char functions will call FT_Render_Glyph automatically
when needed.
2000-06-22 02:17:42 +02:00
|
|
|
A lot of internal modifications have been performed lately on the
|
|
|
|
source in order to provide the following enhancements:
|
2000-10-31 21:42:18 +01:00
|
|
|
|
- MAJOR INTERNAL REDESIGN:
A lot of internal modifications have been performed lately on the
source in order to provide the following enhancements:
- more generic module support:
The FT_Module type is now defined to represent a handle to a given
module. The file <freetype/ftmodule.h> contains the FT_Module_Class
definition, as well as the module-loading public API
The FT_Driver type is still defined, and still represents a pointer
to a font driver. Note that FT_Add_Driver is replaced by FT_Add_Module,
FT_Get_Driver by FT_Get_Module, etc..
- support for generic glyph image types:
The FT_Renderer type is a pointer to a module used to perform various
operations on glyph image.
Each renderer is capable of handling images in a single format
(e.g. ft_glyph_format_outline). Its functions are used to:
- transform an glyph image
- render a glyph image into a bitmap
- return the control box (dimensions) of a given glyph image
The scan converters "ftraster.c" and "ftgrays.c" have been moved
to the new directory "src/renderer", and are used to provide two
default renderer modules.
One corresponds to the "standard" scan-converter, the other to the
"smooth" one.
The current renderer can be set through the new function
FT_Set_Renderer.
The old raster-related function FT_Set_Raster, FT_Get_Raster and
FT_Set_Raster_Mode have now disappeared, in favor of the new:
FT_Get_Renderer
FT_Set_Renderer
see the file <freetype/ftrender.h> for more details..
These changes were necessary to properly support different scalable
formats in the future, like bi-color glyphs, etc..
- glyph loader object:
A new internal object, called a 'glyph loader' has been introduced
in the base layer. It is used by all scalable format font drivers
to load glyphs and composites.
This object has been created to reduce the code size of each driver,
as each one of them basically re-implemented its functionality.
See <freetype/internal/ftobjs.h> and the FT_GlyphLoader type for
more information..
- FT_GlyphSlot had new fields:
In order to support extended features (see below), the FT_GlyphSlot
structure has a few new fields:
linearHoriAdvance: this field gives the linearly scaled (i.e.
scaled but unhinted) advance width for the glyph,
expressed as a 16.16 fixed pixel value. This
is useful to perform WYSIWYG text.
linearVertAdvance: this field gives the linearly scaled advance
height for the glyph (relevant in vertical glyph
layouts only). This is useful to perform
WYSIWYG text.
Note that the two above field replace the removed "metrics2" field
in the glyph slot.
advance: this field is a vector that gives the transformed
advance for the glyph. By default, it corresponds
to the advance width, unless FT_LOAD_VERTICAL_LAYOUT
was specified when calling FT_Load_Glyph or FT_Load_Char
bitmap_left: this field gives the distance in integer pixels from
the current pen position to the left-most pixel of
a glyph image WHEN IT IS A BITMAP. It is only valid
when the "format" field is set to
"ft_glyph_format_bitmap", for example, after calling
the new function FT_Render_Glyph.
bitmap_top: this field gives the distance in integer pixels from
the current pen position (located on the baseline) to
the top-most pixel of the glyph image WHEN IT IS A
BITMAP. Positive values correspond to upwards Y.
loader: this is a new private field for the glyph slot. Client
applications should not touch it..
- support for transforms and direct rendering in FT_Load_Glyph:
Most of the functionality found in <freetype/ftglyph.h> has been
moved to the core library. Hence, the following:
- a transform can be specified for a face through FT_Set_Transform.
this transform is applied by FT_Load_Glyph to scalable glyph images
(i.e. NOT TO BITMAPS) before the function returns, unless the
bit flag FT_LOAD_IGNORE_TRANSFORM was set in the load flags..
- once a glyph image has been loaded, it can be directly converted to
a bitmap by using the new FT_Render_Glyph function. Note that this
function takes the glyph image from the glyph slot, and converts
it to a bitmap whose properties are returned in "face.glyph.bitmap",
"face.glyph.bitmap_left" and "face.glyph.bitmap_top". The original
native image might be lost after the conversion.
- when using the new bit flag FT_LOAD_RENDER, the FT_Load_Glyph
and FT_Load_Char functions will call FT_Render_Glyph automatically
when needed.
2000-06-22 02:17:42 +02:00
|
|
|
- more generic module support:
|
2000-10-31 21:42:18 +01:00
|
|
|
|
- MAJOR INTERNAL REDESIGN:
A lot of internal modifications have been performed lately on the
source in order to provide the following enhancements:
- more generic module support:
The FT_Module type is now defined to represent a handle to a given
module. The file <freetype/ftmodule.h> contains the FT_Module_Class
definition, as well as the module-loading public API
The FT_Driver type is still defined, and still represents a pointer
to a font driver. Note that FT_Add_Driver is replaced by FT_Add_Module,
FT_Get_Driver by FT_Get_Module, etc..
- support for generic glyph image types:
The FT_Renderer type is a pointer to a module used to perform various
operations on glyph image.
Each renderer is capable of handling images in a single format
(e.g. ft_glyph_format_outline). Its functions are used to:
- transform an glyph image
- render a glyph image into a bitmap
- return the control box (dimensions) of a given glyph image
The scan converters "ftraster.c" and "ftgrays.c" have been moved
to the new directory "src/renderer", and are used to provide two
default renderer modules.
One corresponds to the "standard" scan-converter, the other to the
"smooth" one.
The current renderer can be set through the new function
FT_Set_Renderer.
The old raster-related function FT_Set_Raster, FT_Get_Raster and
FT_Set_Raster_Mode have now disappeared, in favor of the new:
FT_Get_Renderer
FT_Set_Renderer
see the file <freetype/ftrender.h> for more details..
These changes were necessary to properly support different scalable
formats in the future, like bi-color glyphs, etc..
- glyph loader object:
A new internal object, called a 'glyph loader' has been introduced
in the base layer. It is used by all scalable format font drivers
to load glyphs and composites.
This object has been created to reduce the code size of each driver,
as each one of them basically re-implemented its functionality.
See <freetype/internal/ftobjs.h> and the FT_GlyphLoader type for
more information..
- FT_GlyphSlot had new fields:
In order to support extended features (see below), the FT_GlyphSlot
structure has a few new fields:
linearHoriAdvance: this field gives the linearly scaled (i.e.
scaled but unhinted) advance width for the glyph,
expressed as a 16.16 fixed pixel value. This
is useful to perform WYSIWYG text.
linearVertAdvance: this field gives the linearly scaled advance
height for the glyph (relevant in vertical glyph
layouts only). This is useful to perform
WYSIWYG text.
Note that the two above field replace the removed "metrics2" field
in the glyph slot.
advance: this field is a vector that gives the transformed
advance for the glyph. By default, it corresponds
to the advance width, unless FT_LOAD_VERTICAL_LAYOUT
was specified when calling FT_Load_Glyph or FT_Load_Char
bitmap_left: this field gives the distance in integer pixels from
the current pen position to the left-most pixel of
a glyph image WHEN IT IS A BITMAP. It is only valid
when the "format" field is set to
"ft_glyph_format_bitmap", for example, after calling
the new function FT_Render_Glyph.
bitmap_top: this field gives the distance in integer pixels from
the current pen position (located on the baseline) to
the top-most pixel of the glyph image WHEN IT IS A
BITMAP. Positive values correspond to upwards Y.
loader: this is a new private field for the glyph slot. Client
applications should not touch it..
- support for transforms and direct rendering in FT_Load_Glyph:
Most of the functionality found in <freetype/ftglyph.h> has been
moved to the core library. Hence, the following:
- a transform can be specified for a face through FT_Set_Transform.
this transform is applied by FT_Load_Glyph to scalable glyph images
(i.e. NOT TO BITMAPS) before the function returns, unless the
bit flag FT_LOAD_IGNORE_TRANSFORM was set in the load flags..
- once a glyph image has been loaded, it can be directly converted to
a bitmap by using the new FT_Render_Glyph function. Note that this
function takes the glyph image from the glyph slot, and converts
it to a bitmap whose properties are returned in "face.glyph.bitmap",
"face.glyph.bitmap_left" and "face.glyph.bitmap_top". The original
native image might be lost after the conversion.
- when using the new bit flag FT_LOAD_RENDER, the FT_Load_Glyph
and FT_Load_Char functions will call FT_Render_Glyph automatically
when needed.
2000-06-22 02:17:42 +02:00
|
|
|
The FT_Module type is now defined to represent a handle to a given
|
|
|
|
module. The file <freetype/ftmodule.h> contains the FT_Module_Class
|
|
|
|
definition, as well as the module-loading public API
|
|
|
|
|
|
|
|
The FT_Driver type is still defined, and still represents a pointer
|
|
|
|
to a font driver. Note that FT_Add_Driver is replaced by FT_Add_Module,
|
|
|
|
FT_Get_Driver by FT_Get_Module, etc..
|
|
|
|
|
|
|
|
|
|
|
|
- support for generic glyph image types:
|
|
|
|
|
|
|
|
The FT_Renderer type is a pointer to a module used to perform various
|
|
|
|
operations on glyph image.
|
2000-10-31 21:42:18 +01:00
|
|
|
|
- MAJOR INTERNAL REDESIGN:
A lot of internal modifications have been performed lately on the
source in order to provide the following enhancements:
- more generic module support:
The FT_Module type is now defined to represent a handle to a given
module. The file <freetype/ftmodule.h> contains the FT_Module_Class
definition, as well as the module-loading public API
The FT_Driver type is still defined, and still represents a pointer
to a font driver. Note that FT_Add_Driver is replaced by FT_Add_Module,
FT_Get_Driver by FT_Get_Module, etc..
- support for generic glyph image types:
The FT_Renderer type is a pointer to a module used to perform various
operations on glyph image.
Each renderer is capable of handling images in a single format
(e.g. ft_glyph_format_outline). Its functions are used to:
- transform an glyph image
- render a glyph image into a bitmap
- return the control box (dimensions) of a given glyph image
The scan converters "ftraster.c" and "ftgrays.c" have been moved
to the new directory "src/renderer", and are used to provide two
default renderer modules.
One corresponds to the "standard" scan-converter, the other to the
"smooth" one.
The current renderer can be set through the new function
FT_Set_Renderer.
The old raster-related function FT_Set_Raster, FT_Get_Raster and
FT_Set_Raster_Mode have now disappeared, in favor of the new:
FT_Get_Renderer
FT_Set_Renderer
see the file <freetype/ftrender.h> for more details..
These changes were necessary to properly support different scalable
formats in the future, like bi-color glyphs, etc..
- glyph loader object:
A new internal object, called a 'glyph loader' has been introduced
in the base layer. It is used by all scalable format font drivers
to load glyphs and composites.
This object has been created to reduce the code size of each driver,
as each one of them basically re-implemented its functionality.
See <freetype/internal/ftobjs.h> and the FT_GlyphLoader type for
more information..
- FT_GlyphSlot had new fields:
In order to support extended features (see below), the FT_GlyphSlot
structure has a few new fields:
linearHoriAdvance: this field gives the linearly scaled (i.e.
scaled but unhinted) advance width for the glyph,
expressed as a 16.16 fixed pixel value. This
is useful to perform WYSIWYG text.
linearVertAdvance: this field gives the linearly scaled advance
height for the glyph (relevant in vertical glyph
layouts only). This is useful to perform
WYSIWYG text.
Note that the two above field replace the removed "metrics2" field
in the glyph slot.
advance: this field is a vector that gives the transformed
advance for the glyph. By default, it corresponds
to the advance width, unless FT_LOAD_VERTICAL_LAYOUT
was specified when calling FT_Load_Glyph or FT_Load_Char
bitmap_left: this field gives the distance in integer pixels from
the current pen position to the left-most pixel of
a glyph image WHEN IT IS A BITMAP. It is only valid
when the "format" field is set to
"ft_glyph_format_bitmap", for example, after calling
the new function FT_Render_Glyph.
bitmap_top: this field gives the distance in integer pixels from
the current pen position (located on the baseline) to
the top-most pixel of the glyph image WHEN IT IS A
BITMAP. Positive values correspond to upwards Y.
loader: this is a new private field for the glyph slot. Client
applications should not touch it..
- support for transforms and direct rendering in FT_Load_Glyph:
Most of the functionality found in <freetype/ftglyph.h> has been
moved to the core library. Hence, the following:
- a transform can be specified for a face through FT_Set_Transform.
this transform is applied by FT_Load_Glyph to scalable glyph images
(i.e. NOT TO BITMAPS) before the function returns, unless the
bit flag FT_LOAD_IGNORE_TRANSFORM was set in the load flags..
- once a glyph image has been loaded, it can be directly converted to
a bitmap by using the new FT_Render_Glyph function. Note that this
function takes the glyph image from the glyph slot, and converts
it to a bitmap whose properties are returned in "face.glyph.bitmap",
"face.glyph.bitmap_left" and "face.glyph.bitmap_top". The original
native image might be lost after the conversion.
- when using the new bit flag FT_LOAD_RENDER, the FT_Load_Glyph
and FT_Load_Char functions will call FT_Render_Glyph automatically
when needed.
2000-06-22 02:17:42 +02:00
|
|
|
Each renderer is capable of handling images in a single format
|
|
|
|
(e.g. ft_glyph_format_outline). Its functions are used to:
|
2000-10-31 21:42:18 +01:00
|
|
|
|
- MAJOR INTERNAL REDESIGN:
A lot of internal modifications have been performed lately on the
source in order to provide the following enhancements:
- more generic module support:
The FT_Module type is now defined to represent a handle to a given
module. The file <freetype/ftmodule.h> contains the FT_Module_Class
definition, as well as the module-loading public API
The FT_Driver type is still defined, and still represents a pointer
to a font driver. Note that FT_Add_Driver is replaced by FT_Add_Module,
FT_Get_Driver by FT_Get_Module, etc..
- support for generic glyph image types:
The FT_Renderer type is a pointer to a module used to perform various
operations on glyph image.
Each renderer is capable of handling images in a single format
(e.g. ft_glyph_format_outline). Its functions are used to:
- transform an glyph image
- render a glyph image into a bitmap
- return the control box (dimensions) of a given glyph image
The scan converters "ftraster.c" and "ftgrays.c" have been moved
to the new directory "src/renderer", and are used to provide two
default renderer modules.
One corresponds to the "standard" scan-converter, the other to the
"smooth" one.
The current renderer can be set through the new function
FT_Set_Renderer.
The old raster-related function FT_Set_Raster, FT_Get_Raster and
FT_Set_Raster_Mode have now disappeared, in favor of the new:
FT_Get_Renderer
FT_Set_Renderer
see the file <freetype/ftrender.h> for more details..
These changes were necessary to properly support different scalable
formats in the future, like bi-color glyphs, etc..
- glyph loader object:
A new internal object, called a 'glyph loader' has been introduced
in the base layer. It is used by all scalable format font drivers
to load glyphs and composites.
This object has been created to reduce the code size of each driver,
as each one of them basically re-implemented its functionality.
See <freetype/internal/ftobjs.h> and the FT_GlyphLoader type for
more information..
- FT_GlyphSlot had new fields:
In order to support extended features (see below), the FT_GlyphSlot
structure has a few new fields:
linearHoriAdvance: this field gives the linearly scaled (i.e.
scaled but unhinted) advance width for the glyph,
expressed as a 16.16 fixed pixel value. This
is useful to perform WYSIWYG text.
linearVertAdvance: this field gives the linearly scaled advance
height for the glyph (relevant in vertical glyph
layouts only). This is useful to perform
WYSIWYG text.
Note that the two above field replace the removed "metrics2" field
in the glyph slot.
advance: this field is a vector that gives the transformed
advance for the glyph. By default, it corresponds
to the advance width, unless FT_LOAD_VERTICAL_LAYOUT
was specified when calling FT_Load_Glyph or FT_Load_Char
bitmap_left: this field gives the distance in integer pixels from
the current pen position to the left-most pixel of
a glyph image WHEN IT IS A BITMAP. It is only valid
when the "format" field is set to
"ft_glyph_format_bitmap", for example, after calling
the new function FT_Render_Glyph.
bitmap_top: this field gives the distance in integer pixels from
the current pen position (located on the baseline) to
the top-most pixel of the glyph image WHEN IT IS A
BITMAP. Positive values correspond to upwards Y.
loader: this is a new private field for the glyph slot. Client
applications should not touch it..
- support for transforms and direct rendering in FT_Load_Glyph:
Most of the functionality found in <freetype/ftglyph.h> has been
moved to the core library. Hence, the following:
- a transform can be specified for a face through FT_Set_Transform.
this transform is applied by FT_Load_Glyph to scalable glyph images
(i.e. NOT TO BITMAPS) before the function returns, unless the
bit flag FT_LOAD_IGNORE_TRANSFORM was set in the load flags..
- once a glyph image has been loaded, it can be directly converted to
a bitmap by using the new FT_Render_Glyph function. Note that this
function takes the glyph image from the glyph slot, and converts
it to a bitmap whose properties are returned in "face.glyph.bitmap",
"face.glyph.bitmap_left" and "face.glyph.bitmap_top". The original
native image might be lost after the conversion.
- when using the new bit flag FT_LOAD_RENDER, the FT_Load_Glyph
and FT_Load_Char functions will call FT_Render_Glyph automatically
when needed.
2000-06-22 02:17:42 +02:00
|
|
|
- transform an glyph image
|
|
|
|
- render a glyph image into a bitmap
|
|
|
|
- return the control box (dimensions) of a given glyph image
|
|
|
|
|
|
|
|
|
|
|
|
The scan converters "ftraster.c" and "ftgrays.c" have been moved
|
|
|
|
to the new directory "src/renderer", and are used to provide two
|
|
|
|
default renderer modules.
|
2000-10-31 21:42:18 +01:00
|
|
|
|
- MAJOR INTERNAL REDESIGN:
A lot of internal modifications have been performed lately on the
source in order to provide the following enhancements:
- more generic module support:
The FT_Module type is now defined to represent a handle to a given
module. The file <freetype/ftmodule.h> contains the FT_Module_Class
definition, as well as the module-loading public API
The FT_Driver type is still defined, and still represents a pointer
to a font driver. Note that FT_Add_Driver is replaced by FT_Add_Module,
FT_Get_Driver by FT_Get_Module, etc..
- support for generic glyph image types:
The FT_Renderer type is a pointer to a module used to perform various
operations on glyph image.
Each renderer is capable of handling images in a single format
(e.g. ft_glyph_format_outline). Its functions are used to:
- transform an glyph image
- render a glyph image into a bitmap
- return the control box (dimensions) of a given glyph image
The scan converters "ftraster.c" and "ftgrays.c" have been moved
to the new directory "src/renderer", and are used to provide two
default renderer modules.
One corresponds to the "standard" scan-converter, the other to the
"smooth" one.
The current renderer can be set through the new function
FT_Set_Renderer.
The old raster-related function FT_Set_Raster, FT_Get_Raster and
FT_Set_Raster_Mode have now disappeared, in favor of the new:
FT_Get_Renderer
FT_Set_Renderer
see the file <freetype/ftrender.h> for more details..
These changes were necessary to properly support different scalable
formats in the future, like bi-color glyphs, etc..
- glyph loader object:
A new internal object, called a 'glyph loader' has been introduced
in the base layer. It is used by all scalable format font drivers
to load glyphs and composites.
This object has been created to reduce the code size of each driver,
as each one of them basically re-implemented its functionality.
See <freetype/internal/ftobjs.h> and the FT_GlyphLoader type for
more information..
- FT_GlyphSlot had new fields:
In order to support extended features (see below), the FT_GlyphSlot
structure has a few new fields:
linearHoriAdvance: this field gives the linearly scaled (i.e.
scaled but unhinted) advance width for the glyph,
expressed as a 16.16 fixed pixel value. This
is useful to perform WYSIWYG text.
linearVertAdvance: this field gives the linearly scaled advance
height for the glyph (relevant in vertical glyph
layouts only). This is useful to perform
WYSIWYG text.
Note that the two above field replace the removed "metrics2" field
in the glyph slot.
advance: this field is a vector that gives the transformed
advance for the glyph. By default, it corresponds
to the advance width, unless FT_LOAD_VERTICAL_LAYOUT
was specified when calling FT_Load_Glyph or FT_Load_Char
bitmap_left: this field gives the distance in integer pixels from
the current pen position to the left-most pixel of
a glyph image WHEN IT IS A BITMAP. It is only valid
when the "format" field is set to
"ft_glyph_format_bitmap", for example, after calling
the new function FT_Render_Glyph.
bitmap_top: this field gives the distance in integer pixels from
the current pen position (located on the baseline) to
the top-most pixel of the glyph image WHEN IT IS A
BITMAP. Positive values correspond to upwards Y.
loader: this is a new private field for the glyph slot. Client
applications should not touch it..
- support for transforms and direct rendering in FT_Load_Glyph:
Most of the functionality found in <freetype/ftglyph.h> has been
moved to the core library. Hence, the following:
- a transform can be specified for a face through FT_Set_Transform.
this transform is applied by FT_Load_Glyph to scalable glyph images
(i.e. NOT TO BITMAPS) before the function returns, unless the
bit flag FT_LOAD_IGNORE_TRANSFORM was set in the load flags..
- once a glyph image has been loaded, it can be directly converted to
a bitmap by using the new FT_Render_Glyph function. Note that this
function takes the glyph image from the glyph slot, and converts
it to a bitmap whose properties are returned in "face.glyph.bitmap",
"face.glyph.bitmap_left" and "face.glyph.bitmap_top". The original
native image might be lost after the conversion.
- when using the new bit flag FT_LOAD_RENDER, the FT_Load_Glyph
and FT_Load_Char functions will call FT_Render_Glyph automatically
when needed.
2000-06-22 02:17:42 +02:00
|
|
|
One corresponds to the "standard" scan-converter, the other to the
|
|
|
|
"smooth" one.
|
2000-10-31 21:42:18 +01:00
|
|
|
|
- MAJOR INTERNAL REDESIGN:
A lot of internal modifications have been performed lately on the
source in order to provide the following enhancements:
- more generic module support:
The FT_Module type is now defined to represent a handle to a given
module. The file <freetype/ftmodule.h> contains the FT_Module_Class
definition, as well as the module-loading public API
The FT_Driver type is still defined, and still represents a pointer
to a font driver. Note that FT_Add_Driver is replaced by FT_Add_Module,
FT_Get_Driver by FT_Get_Module, etc..
- support for generic glyph image types:
The FT_Renderer type is a pointer to a module used to perform various
operations on glyph image.
Each renderer is capable of handling images in a single format
(e.g. ft_glyph_format_outline). Its functions are used to:
- transform an glyph image
- render a glyph image into a bitmap
- return the control box (dimensions) of a given glyph image
The scan converters "ftraster.c" and "ftgrays.c" have been moved
to the new directory "src/renderer", and are used to provide two
default renderer modules.
One corresponds to the "standard" scan-converter, the other to the
"smooth" one.
The current renderer can be set through the new function
FT_Set_Renderer.
The old raster-related function FT_Set_Raster, FT_Get_Raster and
FT_Set_Raster_Mode have now disappeared, in favor of the new:
FT_Get_Renderer
FT_Set_Renderer
see the file <freetype/ftrender.h> for more details..
These changes were necessary to properly support different scalable
formats in the future, like bi-color glyphs, etc..
- glyph loader object:
A new internal object, called a 'glyph loader' has been introduced
in the base layer. It is used by all scalable format font drivers
to load glyphs and composites.
This object has been created to reduce the code size of each driver,
as each one of them basically re-implemented its functionality.
See <freetype/internal/ftobjs.h> and the FT_GlyphLoader type for
more information..
- FT_GlyphSlot had new fields:
In order to support extended features (see below), the FT_GlyphSlot
structure has a few new fields:
linearHoriAdvance: this field gives the linearly scaled (i.e.
scaled but unhinted) advance width for the glyph,
expressed as a 16.16 fixed pixel value. This
is useful to perform WYSIWYG text.
linearVertAdvance: this field gives the linearly scaled advance
height for the glyph (relevant in vertical glyph
layouts only). This is useful to perform
WYSIWYG text.
Note that the two above field replace the removed "metrics2" field
in the glyph slot.
advance: this field is a vector that gives the transformed
advance for the glyph. By default, it corresponds
to the advance width, unless FT_LOAD_VERTICAL_LAYOUT
was specified when calling FT_Load_Glyph or FT_Load_Char
bitmap_left: this field gives the distance in integer pixels from
the current pen position to the left-most pixel of
a glyph image WHEN IT IS A BITMAP. It is only valid
when the "format" field is set to
"ft_glyph_format_bitmap", for example, after calling
the new function FT_Render_Glyph.
bitmap_top: this field gives the distance in integer pixels from
the current pen position (located on the baseline) to
the top-most pixel of the glyph image WHEN IT IS A
BITMAP. Positive values correspond to upwards Y.
loader: this is a new private field for the glyph slot. Client
applications should not touch it..
- support for transforms and direct rendering in FT_Load_Glyph:
Most of the functionality found in <freetype/ftglyph.h> has been
moved to the core library. Hence, the following:
- a transform can be specified for a face through FT_Set_Transform.
this transform is applied by FT_Load_Glyph to scalable glyph images
(i.e. NOT TO BITMAPS) before the function returns, unless the
bit flag FT_LOAD_IGNORE_TRANSFORM was set in the load flags..
- once a glyph image has been loaded, it can be directly converted to
a bitmap by using the new FT_Render_Glyph function. Note that this
function takes the glyph image from the glyph slot, and converts
it to a bitmap whose properties are returned in "face.glyph.bitmap",
"face.glyph.bitmap_left" and "face.glyph.bitmap_top". The original
native image might be lost after the conversion.
- when using the new bit flag FT_LOAD_RENDER, the FT_Load_Glyph
and FT_Load_Char functions will call FT_Render_Glyph automatically
when needed.
2000-06-22 02:17:42 +02:00
|
|
|
The current renderer can be set through the new function
|
|
|
|
FT_Set_Renderer.
|
2000-10-31 21:42:18 +01:00
|
|
|
|
- MAJOR INTERNAL REDESIGN:
A lot of internal modifications have been performed lately on the
source in order to provide the following enhancements:
- more generic module support:
The FT_Module type is now defined to represent a handle to a given
module. The file <freetype/ftmodule.h> contains the FT_Module_Class
definition, as well as the module-loading public API
The FT_Driver type is still defined, and still represents a pointer
to a font driver. Note that FT_Add_Driver is replaced by FT_Add_Module,
FT_Get_Driver by FT_Get_Module, etc..
- support for generic glyph image types:
The FT_Renderer type is a pointer to a module used to perform various
operations on glyph image.
Each renderer is capable of handling images in a single format
(e.g. ft_glyph_format_outline). Its functions are used to:
- transform an glyph image
- render a glyph image into a bitmap
- return the control box (dimensions) of a given glyph image
The scan converters "ftraster.c" and "ftgrays.c" have been moved
to the new directory "src/renderer", and are used to provide two
default renderer modules.
One corresponds to the "standard" scan-converter, the other to the
"smooth" one.
The current renderer can be set through the new function
FT_Set_Renderer.
The old raster-related function FT_Set_Raster, FT_Get_Raster and
FT_Set_Raster_Mode have now disappeared, in favor of the new:
FT_Get_Renderer
FT_Set_Renderer
see the file <freetype/ftrender.h> for more details..
These changes were necessary to properly support different scalable
formats in the future, like bi-color glyphs, etc..
- glyph loader object:
A new internal object, called a 'glyph loader' has been introduced
in the base layer. It is used by all scalable format font drivers
to load glyphs and composites.
This object has been created to reduce the code size of each driver,
as each one of them basically re-implemented its functionality.
See <freetype/internal/ftobjs.h> and the FT_GlyphLoader type for
more information..
- FT_GlyphSlot had new fields:
In order to support extended features (see below), the FT_GlyphSlot
structure has a few new fields:
linearHoriAdvance: this field gives the linearly scaled (i.e.
scaled but unhinted) advance width for the glyph,
expressed as a 16.16 fixed pixel value. This
is useful to perform WYSIWYG text.
linearVertAdvance: this field gives the linearly scaled advance
height for the glyph (relevant in vertical glyph
layouts only). This is useful to perform
WYSIWYG text.
Note that the two above field replace the removed "metrics2" field
in the glyph slot.
advance: this field is a vector that gives the transformed
advance for the glyph. By default, it corresponds
to the advance width, unless FT_LOAD_VERTICAL_LAYOUT
was specified when calling FT_Load_Glyph or FT_Load_Char
bitmap_left: this field gives the distance in integer pixels from
the current pen position to the left-most pixel of
a glyph image WHEN IT IS A BITMAP. It is only valid
when the "format" field is set to
"ft_glyph_format_bitmap", for example, after calling
the new function FT_Render_Glyph.
bitmap_top: this field gives the distance in integer pixels from
the current pen position (located on the baseline) to
the top-most pixel of the glyph image WHEN IT IS A
BITMAP. Positive values correspond to upwards Y.
loader: this is a new private field for the glyph slot. Client
applications should not touch it..
- support for transforms and direct rendering in FT_Load_Glyph:
Most of the functionality found in <freetype/ftglyph.h> has been
moved to the core library. Hence, the following:
- a transform can be specified for a face through FT_Set_Transform.
this transform is applied by FT_Load_Glyph to scalable glyph images
(i.e. NOT TO BITMAPS) before the function returns, unless the
bit flag FT_LOAD_IGNORE_TRANSFORM was set in the load flags..
- once a glyph image has been loaded, it can be directly converted to
a bitmap by using the new FT_Render_Glyph function. Note that this
function takes the glyph image from the glyph slot, and converts
it to a bitmap whose properties are returned in "face.glyph.bitmap",
"face.glyph.bitmap_left" and "face.glyph.bitmap_top". The original
native image might be lost after the conversion.
- when using the new bit flag FT_LOAD_RENDER, the FT_Load_Glyph
and FT_Load_Char functions will call FT_Render_Glyph automatically
when needed.
2000-06-22 02:17:42 +02:00
|
|
|
The old raster-related function FT_Set_Raster, FT_Get_Raster and
|
|
|
|
FT_Set_Raster_Mode have now disappeared, in favor of the new:
|
2000-10-31 21:42:18 +01:00
|
|
|
|
- MAJOR INTERNAL REDESIGN:
A lot of internal modifications have been performed lately on the
source in order to provide the following enhancements:
- more generic module support:
The FT_Module type is now defined to represent a handle to a given
module. The file <freetype/ftmodule.h> contains the FT_Module_Class
definition, as well as the module-loading public API
The FT_Driver type is still defined, and still represents a pointer
to a font driver. Note that FT_Add_Driver is replaced by FT_Add_Module,
FT_Get_Driver by FT_Get_Module, etc..
- support for generic glyph image types:
The FT_Renderer type is a pointer to a module used to perform various
operations on glyph image.
Each renderer is capable of handling images in a single format
(e.g. ft_glyph_format_outline). Its functions are used to:
- transform an glyph image
- render a glyph image into a bitmap
- return the control box (dimensions) of a given glyph image
The scan converters "ftraster.c" and "ftgrays.c" have been moved
to the new directory "src/renderer", and are used to provide two
default renderer modules.
One corresponds to the "standard" scan-converter, the other to the
"smooth" one.
The current renderer can be set through the new function
FT_Set_Renderer.
The old raster-related function FT_Set_Raster, FT_Get_Raster and
FT_Set_Raster_Mode have now disappeared, in favor of the new:
FT_Get_Renderer
FT_Set_Renderer
see the file <freetype/ftrender.h> for more details..
These changes were necessary to properly support different scalable
formats in the future, like bi-color glyphs, etc..
- glyph loader object:
A new internal object, called a 'glyph loader' has been introduced
in the base layer. It is used by all scalable format font drivers
to load glyphs and composites.
This object has been created to reduce the code size of each driver,
as each one of them basically re-implemented its functionality.
See <freetype/internal/ftobjs.h> and the FT_GlyphLoader type for
more information..
- FT_GlyphSlot had new fields:
In order to support extended features (see below), the FT_GlyphSlot
structure has a few new fields:
linearHoriAdvance: this field gives the linearly scaled (i.e.
scaled but unhinted) advance width for the glyph,
expressed as a 16.16 fixed pixel value. This
is useful to perform WYSIWYG text.
linearVertAdvance: this field gives the linearly scaled advance
height for the glyph (relevant in vertical glyph
layouts only). This is useful to perform
WYSIWYG text.
Note that the two above field replace the removed "metrics2" field
in the glyph slot.
advance: this field is a vector that gives the transformed
advance for the glyph. By default, it corresponds
to the advance width, unless FT_LOAD_VERTICAL_LAYOUT
was specified when calling FT_Load_Glyph or FT_Load_Char
bitmap_left: this field gives the distance in integer pixels from
the current pen position to the left-most pixel of
a glyph image WHEN IT IS A BITMAP. It is only valid
when the "format" field is set to
"ft_glyph_format_bitmap", for example, after calling
the new function FT_Render_Glyph.
bitmap_top: this field gives the distance in integer pixels from
the current pen position (located on the baseline) to
the top-most pixel of the glyph image WHEN IT IS A
BITMAP. Positive values correspond to upwards Y.
loader: this is a new private field for the glyph slot. Client
applications should not touch it..
- support for transforms and direct rendering in FT_Load_Glyph:
Most of the functionality found in <freetype/ftglyph.h> has been
moved to the core library. Hence, the following:
- a transform can be specified for a face through FT_Set_Transform.
this transform is applied by FT_Load_Glyph to scalable glyph images
(i.e. NOT TO BITMAPS) before the function returns, unless the
bit flag FT_LOAD_IGNORE_TRANSFORM was set in the load flags..
- once a glyph image has been loaded, it can be directly converted to
a bitmap by using the new FT_Render_Glyph function. Note that this
function takes the glyph image from the glyph slot, and converts
it to a bitmap whose properties are returned in "face.glyph.bitmap",
"face.glyph.bitmap_left" and "face.glyph.bitmap_top". The original
native image might be lost after the conversion.
- when using the new bit flag FT_LOAD_RENDER, the FT_Load_Glyph
and FT_Load_Char functions will call FT_Render_Glyph automatically
when needed.
2000-06-22 02:17:42 +02:00
|
|
|
FT_Get_Renderer
|
|
|
|
FT_Set_Renderer
|
|
|
|
|
|
|
|
see the file <freetype/ftrender.h> for more details..
|
|
|
|
|
|
|
|
These changes were necessary to properly support different scalable
|
|
|
|
formats in the future, like bi-color glyphs, etc..
|
|
|
|
|
|
|
|
|
|
|
|
- glyph loader object:
|
|
|
|
|
|
|
|
A new internal object, called a 'glyph loader' has been introduced
|
|
|
|
in the base layer. It is used by all scalable format font drivers
|
|
|
|
to load glyphs and composites.
|
2000-10-31 21:42:18 +01:00
|
|
|
|
- MAJOR INTERNAL REDESIGN:
A lot of internal modifications have been performed lately on the
source in order to provide the following enhancements:
- more generic module support:
The FT_Module type is now defined to represent a handle to a given
module. The file <freetype/ftmodule.h> contains the FT_Module_Class
definition, as well as the module-loading public API
The FT_Driver type is still defined, and still represents a pointer
to a font driver. Note that FT_Add_Driver is replaced by FT_Add_Module,
FT_Get_Driver by FT_Get_Module, etc..
- support for generic glyph image types:
The FT_Renderer type is a pointer to a module used to perform various
operations on glyph image.
Each renderer is capable of handling images in a single format
(e.g. ft_glyph_format_outline). Its functions are used to:
- transform an glyph image
- render a glyph image into a bitmap
- return the control box (dimensions) of a given glyph image
The scan converters "ftraster.c" and "ftgrays.c" have been moved
to the new directory "src/renderer", and are used to provide two
default renderer modules.
One corresponds to the "standard" scan-converter, the other to the
"smooth" one.
The current renderer can be set through the new function
FT_Set_Renderer.
The old raster-related function FT_Set_Raster, FT_Get_Raster and
FT_Set_Raster_Mode have now disappeared, in favor of the new:
FT_Get_Renderer
FT_Set_Renderer
see the file <freetype/ftrender.h> for more details..
These changes were necessary to properly support different scalable
formats in the future, like bi-color glyphs, etc..
- glyph loader object:
A new internal object, called a 'glyph loader' has been introduced
in the base layer. It is used by all scalable format font drivers
to load glyphs and composites.
This object has been created to reduce the code size of each driver,
as each one of them basically re-implemented its functionality.
See <freetype/internal/ftobjs.h> and the FT_GlyphLoader type for
more information..
- FT_GlyphSlot had new fields:
In order to support extended features (see below), the FT_GlyphSlot
structure has a few new fields:
linearHoriAdvance: this field gives the linearly scaled (i.e.
scaled but unhinted) advance width for the glyph,
expressed as a 16.16 fixed pixel value. This
is useful to perform WYSIWYG text.
linearVertAdvance: this field gives the linearly scaled advance
height for the glyph (relevant in vertical glyph
layouts only). This is useful to perform
WYSIWYG text.
Note that the two above field replace the removed "metrics2" field
in the glyph slot.
advance: this field is a vector that gives the transformed
advance for the glyph. By default, it corresponds
to the advance width, unless FT_LOAD_VERTICAL_LAYOUT
was specified when calling FT_Load_Glyph or FT_Load_Char
bitmap_left: this field gives the distance in integer pixels from
the current pen position to the left-most pixel of
a glyph image WHEN IT IS A BITMAP. It is only valid
when the "format" field is set to
"ft_glyph_format_bitmap", for example, after calling
the new function FT_Render_Glyph.
bitmap_top: this field gives the distance in integer pixels from
the current pen position (located on the baseline) to
the top-most pixel of the glyph image WHEN IT IS A
BITMAP. Positive values correspond to upwards Y.
loader: this is a new private field for the glyph slot. Client
applications should not touch it..
- support for transforms and direct rendering in FT_Load_Glyph:
Most of the functionality found in <freetype/ftglyph.h> has been
moved to the core library. Hence, the following:
- a transform can be specified for a face through FT_Set_Transform.
this transform is applied by FT_Load_Glyph to scalable glyph images
(i.e. NOT TO BITMAPS) before the function returns, unless the
bit flag FT_LOAD_IGNORE_TRANSFORM was set in the load flags..
- once a glyph image has been loaded, it can be directly converted to
a bitmap by using the new FT_Render_Glyph function. Note that this
function takes the glyph image from the glyph slot, and converts
it to a bitmap whose properties are returned in "face.glyph.bitmap",
"face.glyph.bitmap_left" and "face.glyph.bitmap_top". The original
native image might be lost after the conversion.
- when using the new bit flag FT_LOAD_RENDER, the FT_Load_Glyph
and FT_Load_Char functions will call FT_Render_Glyph automatically
when needed.
2000-06-22 02:17:42 +02:00
|
|
|
This object has been created to reduce the code size of each driver,
|
|
|
|
as each one of them basically re-implemented its functionality.
|
|
|
|
|
|
|
|
See <freetype/internal/ftobjs.h> and the FT_GlyphLoader type for
|
|
|
|
more information..
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- FT_GlyphSlot had new fields:
|
|
|
|
|
|
|
|
In order to support extended features (see below), the FT_GlyphSlot
|
|
|
|
structure has a few new fields:
|
2000-10-31 21:42:18 +01:00
|
|
|
|
- MAJOR INTERNAL REDESIGN:
A lot of internal modifications have been performed lately on the
source in order to provide the following enhancements:
- more generic module support:
The FT_Module type is now defined to represent a handle to a given
module. The file <freetype/ftmodule.h> contains the FT_Module_Class
definition, as well as the module-loading public API
The FT_Driver type is still defined, and still represents a pointer
to a font driver. Note that FT_Add_Driver is replaced by FT_Add_Module,
FT_Get_Driver by FT_Get_Module, etc..
- support for generic glyph image types:
The FT_Renderer type is a pointer to a module used to perform various
operations on glyph image.
Each renderer is capable of handling images in a single format
(e.g. ft_glyph_format_outline). Its functions are used to:
- transform an glyph image
- render a glyph image into a bitmap
- return the control box (dimensions) of a given glyph image
The scan converters "ftraster.c" and "ftgrays.c" have been moved
to the new directory "src/renderer", and are used to provide two
default renderer modules.
One corresponds to the "standard" scan-converter, the other to the
"smooth" one.
The current renderer can be set through the new function
FT_Set_Renderer.
The old raster-related function FT_Set_Raster, FT_Get_Raster and
FT_Set_Raster_Mode have now disappeared, in favor of the new:
FT_Get_Renderer
FT_Set_Renderer
see the file <freetype/ftrender.h> for more details..
These changes were necessary to properly support different scalable
formats in the future, like bi-color glyphs, etc..
- glyph loader object:
A new internal object, called a 'glyph loader' has been introduced
in the base layer. It is used by all scalable format font drivers
to load glyphs and composites.
This object has been created to reduce the code size of each driver,
as each one of them basically re-implemented its functionality.
See <freetype/internal/ftobjs.h> and the FT_GlyphLoader type for
more information..
- FT_GlyphSlot had new fields:
In order to support extended features (see below), the FT_GlyphSlot
structure has a few new fields:
linearHoriAdvance: this field gives the linearly scaled (i.e.
scaled but unhinted) advance width for the glyph,
expressed as a 16.16 fixed pixel value. This
is useful to perform WYSIWYG text.
linearVertAdvance: this field gives the linearly scaled advance
height for the glyph (relevant in vertical glyph
layouts only). This is useful to perform
WYSIWYG text.
Note that the two above field replace the removed "metrics2" field
in the glyph slot.
advance: this field is a vector that gives the transformed
advance for the glyph. By default, it corresponds
to the advance width, unless FT_LOAD_VERTICAL_LAYOUT
was specified when calling FT_Load_Glyph or FT_Load_Char
bitmap_left: this field gives the distance in integer pixels from
the current pen position to the left-most pixel of
a glyph image WHEN IT IS A BITMAP. It is only valid
when the "format" field is set to
"ft_glyph_format_bitmap", for example, after calling
the new function FT_Render_Glyph.
bitmap_top: this field gives the distance in integer pixels from
the current pen position (located on the baseline) to
the top-most pixel of the glyph image WHEN IT IS A
BITMAP. Positive values correspond to upwards Y.
loader: this is a new private field for the glyph slot. Client
applications should not touch it..
- support for transforms and direct rendering in FT_Load_Glyph:
Most of the functionality found in <freetype/ftglyph.h> has been
moved to the core library. Hence, the following:
- a transform can be specified for a face through FT_Set_Transform.
this transform is applied by FT_Load_Glyph to scalable glyph images
(i.e. NOT TO BITMAPS) before the function returns, unless the
bit flag FT_LOAD_IGNORE_TRANSFORM was set in the load flags..
- once a glyph image has been loaded, it can be directly converted to
a bitmap by using the new FT_Render_Glyph function. Note that this
function takes the glyph image from the glyph slot, and converts
it to a bitmap whose properties are returned in "face.glyph.bitmap",
"face.glyph.bitmap_left" and "face.glyph.bitmap_top". The original
native image might be lost after the conversion.
- when using the new bit flag FT_LOAD_RENDER, the FT_Load_Glyph
and FT_Load_Char functions will call FT_Render_Glyph automatically
when needed.
2000-06-22 02:17:42 +02:00
|
|
|
linearHoriAdvance: this field gives the linearly scaled (i.e.
|
|
|
|
scaled but unhinted) advance width for the glyph,
|
|
|
|
expressed as a 16.16 fixed pixel value. This
|
|
|
|
is useful to perform WYSIWYG text.
|
2000-10-31 21:42:18 +01:00
|
|
|
|
- MAJOR INTERNAL REDESIGN:
A lot of internal modifications have been performed lately on the
source in order to provide the following enhancements:
- more generic module support:
The FT_Module type is now defined to represent a handle to a given
module. The file <freetype/ftmodule.h> contains the FT_Module_Class
definition, as well as the module-loading public API
The FT_Driver type is still defined, and still represents a pointer
to a font driver. Note that FT_Add_Driver is replaced by FT_Add_Module,
FT_Get_Driver by FT_Get_Module, etc..
- support for generic glyph image types:
The FT_Renderer type is a pointer to a module used to perform various
operations on glyph image.
Each renderer is capable of handling images in a single format
(e.g. ft_glyph_format_outline). Its functions are used to:
- transform an glyph image
- render a glyph image into a bitmap
- return the control box (dimensions) of a given glyph image
The scan converters "ftraster.c" and "ftgrays.c" have been moved
to the new directory "src/renderer", and are used to provide two
default renderer modules.
One corresponds to the "standard" scan-converter, the other to the
"smooth" one.
The current renderer can be set through the new function
FT_Set_Renderer.
The old raster-related function FT_Set_Raster, FT_Get_Raster and
FT_Set_Raster_Mode have now disappeared, in favor of the new:
FT_Get_Renderer
FT_Set_Renderer
see the file <freetype/ftrender.h> for more details..
These changes were necessary to properly support different scalable
formats in the future, like bi-color glyphs, etc..
- glyph loader object:
A new internal object, called a 'glyph loader' has been introduced
in the base layer. It is used by all scalable format font drivers
to load glyphs and composites.
This object has been created to reduce the code size of each driver,
as each one of them basically re-implemented its functionality.
See <freetype/internal/ftobjs.h> and the FT_GlyphLoader type for
more information..
- FT_GlyphSlot had new fields:
In order to support extended features (see below), the FT_GlyphSlot
structure has a few new fields:
linearHoriAdvance: this field gives the linearly scaled (i.e.
scaled but unhinted) advance width for the glyph,
expressed as a 16.16 fixed pixel value. This
is useful to perform WYSIWYG text.
linearVertAdvance: this field gives the linearly scaled advance
height for the glyph (relevant in vertical glyph
layouts only). This is useful to perform
WYSIWYG text.
Note that the two above field replace the removed "metrics2" field
in the glyph slot.
advance: this field is a vector that gives the transformed
advance for the glyph. By default, it corresponds
to the advance width, unless FT_LOAD_VERTICAL_LAYOUT
was specified when calling FT_Load_Glyph or FT_Load_Char
bitmap_left: this field gives the distance in integer pixels from
the current pen position to the left-most pixel of
a glyph image WHEN IT IS A BITMAP. It is only valid
when the "format" field is set to
"ft_glyph_format_bitmap", for example, after calling
the new function FT_Render_Glyph.
bitmap_top: this field gives the distance in integer pixels from
the current pen position (located on the baseline) to
the top-most pixel of the glyph image WHEN IT IS A
BITMAP. Positive values correspond to upwards Y.
loader: this is a new private field for the glyph slot. Client
applications should not touch it..
- support for transforms and direct rendering in FT_Load_Glyph:
Most of the functionality found in <freetype/ftglyph.h> has been
moved to the core library. Hence, the following:
- a transform can be specified for a face through FT_Set_Transform.
this transform is applied by FT_Load_Glyph to scalable glyph images
(i.e. NOT TO BITMAPS) before the function returns, unless the
bit flag FT_LOAD_IGNORE_TRANSFORM was set in the load flags..
- once a glyph image has been loaded, it can be directly converted to
a bitmap by using the new FT_Render_Glyph function. Note that this
function takes the glyph image from the glyph slot, and converts
it to a bitmap whose properties are returned in "face.glyph.bitmap",
"face.glyph.bitmap_left" and "face.glyph.bitmap_top". The original
native image might be lost after the conversion.
- when using the new bit flag FT_LOAD_RENDER, the FT_Load_Glyph
and FT_Load_Char functions will call FT_Render_Glyph automatically
when needed.
2000-06-22 02:17:42 +02:00
|
|
|
linearVertAdvance: this field gives the linearly scaled advance
|
|
|
|
height for the glyph (relevant in vertical glyph
|
|
|
|
layouts only). This is useful to perform
|
2000-10-31 21:42:18 +01:00
|
|
|
WYSIWYG text.
|
- MAJOR INTERNAL REDESIGN:
A lot of internal modifications have been performed lately on the
source in order to provide the following enhancements:
- more generic module support:
The FT_Module type is now defined to represent a handle to a given
module. The file <freetype/ftmodule.h> contains the FT_Module_Class
definition, as well as the module-loading public API
The FT_Driver type is still defined, and still represents a pointer
to a font driver. Note that FT_Add_Driver is replaced by FT_Add_Module,
FT_Get_Driver by FT_Get_Module, etc..
- support for generic glyph image types:
The FT_Renderer type is a pointer to a module used to perform various
operations on glyph image.
Each renderer is capable of handling images in a single format
(e.g. ft_glyph_format_outline). Its functions are used to:
- transform an glyph image
- render a glyph image into a bitmap
- return the control box (dimensions) of a given glyph image
The scan converters "ftraster.c" and "ftgrays.c" have been moved
to the new directory "src/renderer", and are used to provide two
default renderer modules.
One corresponds to the "standard" scan-converter, the other to the
"smooth" one.
The current renderer can be set through the new function
FT_Set_Renderer.
The old raster-related function FT_Set_Raster, FT_Get_Raster and
FT_Set_Raster_Mode have now disappeared, in favor of the new:
FT_Get_Renderer
FT_Set_Renderer
see the file <freetype/ftrender.h> for more details..
These changes were necessary to properly support different scalable
formats in the future, like bi-color glyphs, etc..
- glyph loader object:
A new internal object, called a 'glyph loader' has been introduced
in the base layer. It is used by all scalable format font drivers
to load glyphs and composites.
This object has been created to reduce the code size of each driver,
as each one of them basically re-implemented its functionality.
See <freetype/internal/ftobjs.h> and the FT_GlyphLoader type for
more information..
- FT_GlyphSlot had new fields:
In order to support extended features (see below), the FT_GlyphSlot
structure has a few new fields:
linearHoriAdvance: this field gives the linearly scaled (i.e.
scaled but unhinted) advance width for the glyph,
expressed as a 16.16 fixed pixel value. This
is useful to perform WYSIWYG text.
linearVertAdvance: this field gives the linearly scaled advance
height for the glyph (relevant in vertical glyph
layouts only). This is useful to perform
WYSIWYG text.
Note that the two above field replace the removed "metrics2" field
in the glyph slot.
advance: this field is a vector that gives the transformed
advance for the glyph. By default, it corresponds
to the advance width, unless FT_LOAD_VERTICAL_LAYOUT
was specified when calling FT_Load_Glyph or FT_Load_Char
bitmap_left: this field gives the distance in integer pixels from
the current pen position to the left-most pixel of
a glyph image WHEN IT IS A BITMAP. It is only valid
when the "format" field is set to
"ft_glyph_format_bitmap", for example, after calling
the new function FT_Render_Glyph.
bitmap_top: this field gives the distance in integer pixels from
the current pen position (located on the baseline) to
the top-most pixel of the glyph image WHEN IT IS A
BITMAP. Positive values correspond to upwards Y.
loader: this is a new private field for the glyph slot. Client
applications should not touch it..
- support for transforms and direct rendering in FT_Load_Glyph:
Most of the functionality found in <freetype/ftglyph.h> has been
moved to the core library. Hence, the following:
- a transform can be specified for a face through FT_Set_Transform.
this transform is applied by FT_Load_Glyph to scalable glyph images
(i.e. NOT TO BITMAPS) before the function returns, unless the
bit flag FT_LOAD_IGNORE_TRANSFORM was set in the load flags..
- once a glyph image has been loaded, it can be directly converted to
a bitmap by using the new FT_Render_Glyph function. Note that this
function takes the glyph image from the glyph slot, and converts
it to a bitmap whose properties are returned in "face.glyph.bitmap",
"face.glyph.bitmap_left" and "face.glyph.bitmap_top". The original
native image might be lost after the conversion.
- when using the new bit flag FT_LOAD_RENDER, the FT_Load_Glyph
and FT_Load_Char functions will call FT_Render_Glyph automatically
when needed.
2000-06-22 02:17:42 +02:00
|
|
|
|
|
|
|
Note that the two above field replace the removed "metrics2" field
|
|
|
|
in the glyph slot.
|
2000-10-31 21:42:18 +01:00
|
|
|
|
- MAJOR INTERNAL REDESIGN:
A lot of internal modifications have been performed lately on the
source in order to provide the following enhancements:
- more generic module support:
The FT_Module type is now defined to represent a handle to a given
module. The file <freetype/ftmodule.h> contains the FT_Module_Class
definition, as well as the module-loading public API
The FT_Driver type is still defined, and still represents a pointer
to a font driver. Note that FT_Add_Driver is replaced by FT_Add_Module,
FT_Get_Driver by FT_Get_Module, etc..
- support for generic glyph image types:
The FT_Renderer type is a pointer to a module used to perform various
operations on glyph image.
Each renderer is capable of handling images in a single format
(e.g. ft_glyph_format_outline). Its functions are used to:
- transform an glyph image
- render a glyph image into a bitmap
- return the control box (dimensions) of a given glyph image
The scan converters "ftraster.c" and "ftgrays.c" have been moved
to the new directory "src/renderer", and are used to provide two
default renderer modules.
One corresponds to the "standard" scan-converter, the other to the
"smooth" one.
The current renderer can be set through the new function
FT_Set_Renderer.
The old raster-related function FT_Set_Raster, FT_Get_Raster and
FT_Set_Raster_Mode have now disappeared, in favor of the new:
FT_Get_Renderer
FT_Set_Renderer
see the file <freetype/ftrender.h> for more details..
These changes were necessary to properly support different scalable
formats in the future, like bi-color glyphs, etc..
- glyph loader object:
A new internal object, called a 'glyph loader' has been introduced
in the base layer. It is used by all scalable format font drivers
to load glyphs and composites.
This object has been created to reduce the code size of each driver,
as each one of them basically re-implemented its functionality.
See <freetype/internal/ftobjs.h> and the FT_GlyphLoader type for
more information..
- FT_GlyphSlot had new fields:
In order to support extended features (see below), the FT_GlyphSlot
structure has a few new fields:
linearHoriAdvance: this field gives the linearly scaled (i.e.
scaled but unhinted) advance width for the glyph,
expressed as a 16.16 fixed pixel value. This
is useful to perform WYSIWYG text.
linearVertAdvance: this field gives the linearly scaled advance
height for the glyph (relevant in vertical glyph
layouts only). This is useful to perform
WYSIWYG text.
Note that the two above field replace the removed "metrics2" field
in the glyph slot.
advance: this field is a vector that gives the transformed
advance for the glyph. By default, it corresponds
to the advance width, unless FT_LOAD_VERTICAL_LAYOUT
was specified when calling FT_Load_Glyph or FT_Load_Char
bitmap_left: this field gives the distance in integer pixels from
the current pen position to the left-most pixel of
a glyph image WHEN IT IS A BITMAP. It is only valid
when the "format" field is set to
"ft_glyph_format_bitmap", for example, after calling
the new function FT_Render_Glyph.
bitmap_top: this field gives the distance in integer pixels from
the current pen position (located on the baseline) to
the top-most pixel of the glyph image WHEN IT IS A
BITMAP. Positive values correspond to upwards Y.
loader: this is a new private field for the glyph slot. Client
applications should not touch it..
- support for transforms and direct rendering in FT_Load_Glyph:
Most of the functionality found in <freetype/ftglyph.h> has been
moved to the core library. Hence, the following:
- a transform can be specified for a face through FT_Set_Transform.
this transform is applied by FT_Load_Glyph to scalable glyph images
(i.e. NOT TO BITMAPS) before the function returns, unless the
bit flag FT_LOAD_IGNORE_TRANSFORM was set in the load flags..
- once a glyph image has been loaded, it can be directly converted to
a bitmap by using the new FT_Render_Glyph function. Note that this
function takes the glyph image from the glyph slot, and converts
it to a bitmap whose properties are returned in "face.glyph.bitmap",
"face.glyph.bitmap_left" and "face.glyph.bitmap_top". The original
native image might be lost after the conversion.
- when using the new bit flag FT_LOAD_RENDER, the FT_Load_Glyph
and FT_Load_Char functions will call FT_Render_Glyph automatically
when needed.
2000-06-22 02:17:42 +02:00
|
|
|
advance: this field is a vector that gives the transformed
|
|
|
|
advance for the glyph. By default, it corresponds
|
|
|
|
to the advance width, unless FT_LOAD_VERTICAL_LAYOUT
|
|
|
|
was specified when calling FT_Load_Glyph or FT_Load_Char
|
|
|
|
|
|
|
|
bitmap_left: this field gives the distance in integer pixels from
|
|
|
|
the current pen position to the left-most pixel of
|
|
|
|
a glyph image WHEN IT IS A BITMAP. It is only valid
|
|
|
|
when the "format" field is set to
|
|
|
|
"ft_glyph_format_bitmap", for example, after calling
|
|
|
|
the new function FT_Render_Glyph.
|
2000-10-31 21:42:18 +01:00
|
|
|
|
- MAJOR INTERNAL REDESIGN:
A lot of internal modifications have been performed lately on the
source in order to provide the following enhancements:
- more generic module support:
The FT_Module type is now defined to represent a handle to a given
module. The file <freetype/ftmodule.h> contains the FT_Module_Class
definition, as well as the module-loading public API
The FT_Driver type is still defined, and still represents a pointer
to a font driver. Note that FT_Add_Driver is replaced by FT_Add_Module,
FT_Get_Driver by FT_Get_Module, etc..
- support for generic glyph image types:
The FT_Renderer type is a pointer to a module used to perform various
operations on glyph image.
Each renderer is capable of handling images in a single format
(e.g. ft_glyph_format_outline). Its functions are used to:
- transform an glyph image
- render a glyph image into a bitmap
- return the control box (dimensions) of a given glyph image
The scan converters "ftraster.c" and "ftgrays.c" have been moved
to the new directory "src/renderer", and are used to provide two
default renderer modules.
One corresponds to the "standard" scan-converter, the other to the
"smooth" one.
The current renderer can be set through the new function
FT_Set_Renderer.
The old raster-related function FT_Set_Raster, FT_Get_Raster and
FT_Set_Raster_Mode have now disappeared, in favor of the new:
FT_Get_Renderer
FT_Set_Renderer
see the file <freetype/ftrender.h> for more details..
These changes were necessary to properly support different scalable
formats in the future, like bi-color glyphs, etc..
- glyph loader object:
A new internal object, called a 'glyph loader' has been introduced
in the base layer. It is used by all scalable format font drivers
to load glyphs and composites.
This object has been created to reduce the code size of each driver,
as each one of them basically re-implemented its functionality.
See <freetype/internal/ftobjs.h> and the FT_GlyphLoader type for
more information..
- FT_GlyphSlot had new fields:
In order to support extended features (see below), the FT_GlyphSlot
structure has a few new fields:
linearHoriAdvance: this field gives the linearly scaled (i.e.
scaled but unhinted) advance width for the glyph,
expressed as a 16.16 fixed pixel value. This
is useful to perform WYSIWYG text.
linearVertAdvance: this field gives the linearly scaled advance
height for the glyph (relevant in vertical glyph
layouts only). This is useful to perform
WYSIWYG text.
Note that the two above field replace the removed "metrics2" field
in the glyph slot.
advance: this field is a vector that gives the transformed
advance for the glyph. By default, it corresponds
to the advance width, unless FT_LOAD_VERTICAL_LAYOUT
was specified when calling FT_Load_Glyph or FT_Load_Char
bitmap_left: this field gives the distance in integer pixels from
the current pen position to the left-most pixel of
a glyph image WHEN IT IS A BITMAP. It is only valid
when the "format" field is set to
"ft_glyph_format_bitmap", for example, after calling
the new function FT_Render_Glyph.
bitmap_top: this field gives the distance in integer pixels from
the current pen position (located on the baseline) to
the top-most pixel of the glyph image WHEN IT IS A
BITMAP. Positive values correspond to upwards Y.
loader: this is a new private field for the glyph slot. Client
applications should not touch it..
- support for transforms and direct rendering in FT_Load_Glyph:
Most of the functionality found in <freetype/ftglyph.h> has been
moved to the core library. Hence, the following:
- a transform can be specified for a face through FT_Set_Transform.
this transform is applied by FT_Load_Glyph to scalable glyph images
(i.e. NOT TO BITMAPS) before the function returns, unless the
bit flag FT_LOAD_IGNORE_TRANSFORM was set in the load flags..
- once a glyph image has been loaded, it can be directly converted to
a bitmap by using the new FT_Render_Glyph function. Note that this
function takes the glyph image from the glyph slot, and converts
it to a bitmap whose properties are returned in "face.glyph.bitmap",
"face.glyph.bitmap_left" and "face.glyph.bitmap_top". The original
native image might be lost after the conversion.
- when using the new bit flag FT_LOAD_RENDER, the FT_Load_Glyph
and FT_Load_Char functions will call FT_Render_Glyph automatically
when needed.
2000-06-22 02:17:42 +02:00
|
|
|
bitmap_top: this field gives the distance in integer pixels from
|
|
|
|
the current pen position (located on the baseline) to
|
|
|
|
the top-most pixel of the glyph image WHEN IT IS A
|
|
|
|
BITMAP. Positive values correspond to upwards Y.
|
|
|
|
|
|
|
|
loader: this is a new private field for the glyph slot. Client
|
|
|
|
applications should not touch it..
|
|
|
|
|
|
|
|
|
|
|
|
- support for transforms and direct rendering in FT_Load_Glyph:
|
|
|
|
|
|
|
|
Most of the functionality found in <freetype/ftglyph.h> has been
|
|
|
|
moved to the core library. Hence, the following:
|
2000-10-31 21:42:18 +01:00
|
|
|
|
- MAJOR INTERNAL REDESIGN:
A lot of internal modifications have been performed lately on the
source in order to provide the following enhancements:
- more generic module support:
The FT_Module type is now defined to represent a handle to a given
module. The file <freetype/ftmodule.h> contains the FT_Module_Class
definition, as well as the module-loading public API
The FT_Driver type is still defined, and still represents a pointer
to a font driver. Note that FT_Add_Driver is replaced by FT_Add_Module,
FT_Get_Driver by FT_Get_Module, etc..
- support for generic glyph image types:
The FT_Renderer type is a pointer to a module used to perform various
operations on glyph image.
Each renderer is capable of handling images in a single format
(e.g. ft_glyph_format_outline). Its functions are used to:
- transform an glyph image
- render a glyph image into a bitmap
- return the control box (dimensions) of a given glyph image
The scan converters "ftraster.c" and "ftgrays.c" have been moved
to the new directory "src/renderer", and are used to provide two
default renderer modules.
One corresponds to the "standard" scan-converter, the other to the
"smooth" one.
The current renderer can be set through the new function
FT_Set_Renderer.
The old raster-related function FT_Set_Raster, FT_Get_Raster and
FT_Set_Raster_Mode have now disappeared, in favor of the new:
FT_Get_Renderer
FT_Set_Renderer
see the file <freetype/ftrender.h> for more details..
These changes were necessary to properly support different scalable
formats in the future, like bi-color glyphs, etc..
- glyph loader object:
A new internal object, called a 'glyph loader' has been introduced
in the base layer. It is used by all scalable format font drivers
to load glyphs and composites.
This object has been created to reduce the code size of each driver,
as each one of them basically re-implemented its functionality.
See <freetype/internal/ftobjs.h> and the FT_GlyphLoader type for
more information..
- FT_GlyphSlot had new fields:
In order to support extended features (see below), the FT_GlyphSlot
structure has a few new fields:
linearHoriAdvance: this field gives the linearly scaled (i.e.
scaled but unhinted) advance width for the glyph,
expressed as a 16.16 fixed pixel value. This
is useful to perform WYSIWYG text.
linearVertAdvance: this field gives the linearly scaled advance
height for the glyph (relevant in vertical glyph
layouts only). This is useful to perform
WYSIWYG text.
Note that the two above field replace the removed "metrics2" field
in the glyph slot.
advance: this field is a vector that gives the transformed
advance for the glyph. By default, it corresponds
to the advance width, unless FT_LOAD_VERTICAL_LAYOUT
was specified when calling FT_Load_Glyph or FT_Load_Char
bitmap_left: this field gives the distance in integer pixels from
the current pen position to the left-most pixel of
a glyph image WHEN IT IS A BITMAP. It is only valid
when the "format" field is set to
"ft_glyph_format_bitmap", for example, after calling
the new function FT_Render_Glyph.
bitmap_top: this field gives the distance in integer pixels from
the current pen position (located on the baseline) to
the top-most pixel of the glyph image WHEN IT IS A
BITMAP. Positive values correspond to upwards Y.
loader: this is a new private field for the glyph slot. Client
applications should not touch it..
- support for transforms and direct rendering in FT_Load_Glyph:
Most of the functionality found in <freetype/ftglyph.h> has been
moved to the core library. Hence, the following:
- a transform can be specified for a face through FT_Set_Transform.
this transform is applied by FT_Load_Glyph to scalable glyph images
(i.e. NOT TO BITMAPS) before the function returns, unless the
bit flag FT_LOAD_IGNORE_TRANSFORM was set in the load flags..
- once a glyph image has been loaded, it can be directly converted to
a bitmap by using the new FT_Render_Glyph function. Note that this
function takes the glyph image from the glyph slot, and converts
it to a bitmap whose properties are returned in "face.glyph.bitmap",
"face.glyph.bitmap_left" and "face.glyph.bitmap_top". The original
native image might be lost after the conversion.
- when using the new bit flag FT_LOAD_RENDER, the FT_Load_Glyph
and FT_Load_Char functions will call FT_Render_Glyph automatically
when needed.
2000-06-22 02:17:42 +02:00
|
|
|
- a transform can be specified for a face through FT_Set_Transform.
|
|
|
|
this transform is applied by FT_Load_Glyph to scalable glyph images
|
|
|
|
(i.e. NOT TO BITMAPS) before the function returns, unless the
|
|
|
|
bit flag FT_LOAD_IGNORE_TRANSFORM was set in the load flags..
|
|
|
|
|
|
|
|
|
|
|
|
- once a glyph image has been loaded, it can be directly converted to
|
|
|
|
a bitmap by using the new FT_Render_Glyph function. Note that this
|
|
|
|
function takes the glyph image from the glyph slot, and converts
|
|
|
|
it to a bitmap whose properties are returned in "face.glyph.bitmap",
|
|
|
|
"face.glyph.bitmap_left" and "face.glyph.bitmap_top". The original
|
|
|
|
native image might be lost after the conversion.
|
|
|
|
|
|
|
|
|
|
|
|
- when using the new bit flag FT_LOAD_RENDER, the FT_Load_Glyph
|
|
|
|
and FT_Load_Char functions will call FT_Render_Glyph automatically
|
|
|
|
when needed.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2000-06-16 21:34:52 +02:00
|
|
|
- reformated all modules source code in order to get rid of the basic
|
|
|
|
data types redifinitions (i.e. "TT_Int" instead of "FT_Int", "T1_Fixed"
|
|
|
|
instead of "FT_Fixed"). Hence the format-specific prefixes like "TT_",
|
|
|
|
"T1_", "T2_" and "CID_" are only used for relevant structures..
|
|
|
|
|
|
|
|
============================================================================
|
|
|
|
OLD CHANGES FOR BETA 7
|
2000-05-17 22:56:01 +02:00
|
|
|
|
2000-06-08 01:41:17 +02:00
|
|
|
- bug-fixed the OpenType/CFF parser. It now loads and displays my two
|
|
|
|
fonts nicely, but I'm pretty certain that more testing is needed :-)
|
2000-10-31 21:42:18 +01:00
|
|
|
|
2000-06-08 01:41:17 +02:00
|
|
|
- fixed the crummy Type 1 hinter, it now handles accented characters
|
|
|
|
correctly (well, the accent is not always well placed, but that's
|
|
|
|
another problem..)
|
|
|
|
|
2000-06-01 05:27:48 +02:00
|
|
|
- added the CID-keyed Type 1 driver in "src/cid". Works pretty well for
|
|
|
|
only 13 Kb of code ;-) Doesn't read AFM files though, nor the really
|
|
|
|
useful CMAP files..
|
|
|
|
|
|
|
|
- fixed two bugs in the smooth renderer (src/base/ftgrays.c). Thanks to
|
|
|
|
Boris Letocha for spotting them and providing a fix..
|
|
|
|
|
2000-05-29 22:55:13 +02:00
|
|
|
- fixed potential "divide by zero" bugs in ftcalc.c.. my god..
|
|
|
|
|
|
|
|
- added source code for the OpenType/CFF driver (still incomplete though..)
|
|
|
|
|
|
|
|
- modified the SFNT driver slightly to perform more robust header
|
|
|
|
checks in TT_Load_SFNT_Header. This prevents certain font files
|
|
|
|
(e.g. some Type 1 Multiple Masters) from being incorrectly "recognized"
|
|
|
|
as TrueType font files..
|
|
|
|
|
2000-05-27 00:13:17 +02:00
|
|
|
- moved a lot of stuff from the TrueType driver to the SFNT module,
|
|
|
|
this allows greater code re-use between font drivers (e.g. TrueType,
|
|
|
|
OpenType, Compact-TrueType, etc..)
|
|
|
|
|
|
|
|
- added a tiny segment cache to the SFNT Charmap 4 decoder, in order
|
|
|
|
to minimally speed it up..
|
|
|
|
|
2000-05-26 19:13:23 +02:00
|
|
|
- added support for Multiple Master fonts in "type1z". There is also
|
|
|
|
a new file named <freetype/ftmm.h> which defines functions to
|
|
|
|
manage them from client applications.
|
2000-10-31 21:42:18 +01:00
|
|
|
|
2000-05-26 19:13:23 +02:00
|
|
|
The new file "src/base/ftmm.c" is also optional to the engine..
|
|
|
|
|
|
|
|
- various formatting changes (e.g. EXPORT_DEF -> FT_EXPORT_DEF) +
|
|
|
|
small bug fixes in FT_Load_Glyph, the "type1" driver, etc..
|
|
|
|
|
2000-05-24 00:16:27 +02:00
|
|
|
- a minor fix to the Type 1 driver to let them apply the font matrix
|
|
|
|
correctly (used for many oblique fonts..)
|
|
|
|
|
2000-05-18 18:18:05 +02:00
|
|
|
- some fixes for 64-bit systems (mainly changing some FT_TRACE calls
|
|
|
|
to use %p instead of %lx).. Thanks to Karl Robillard
|
|
|
|
|
2000-05-18 01:35:37 +02:00
|
|
|
- fixed some bugs in the sbit loader (src/base/sfnt/ttsbit.c) + added
|
|
|
|
a new flag, FT_LOAD_CROP_BITMAP to query that bitmaps be cropped when
|
|
|
|
loaded from a file (maybe I should move the bitmap cropper to the
|
|
|
|
base layer ??).
|
|
|
|
|
2000-05-17 22:56:01 +02:00
|
|
|
- changed the default number of gray levels of the smooth renderer to
|
|
|
|
256 (instead of the previous 128). Of course, the human eye can't
|
2000-10-28 19:10:06 +02:00
|
|
|
see any difference ;-)
|
2000-05-17 22:56:01 +02:00
|
|
|
|
|
|
|
- removed TT_MAX_SUBGLYPHS, there is no static limit on the number of
|
|
|
|
subglyphs in a TrueType font now..
|
|
|
|
|
|
|
|
=============================================================================
|
|
|
|
OLD CHANGES 16 May 2000
|
2000-05-11 20:23:52 +02:00
|
|
|
|
2000-05-17 01:26:01 +02:00
|
|
|
- tagged "BETA-6" in the CVS tree. This one is a serious release candidate
|
|
|
|
even though it doesn't incorporate the auto-hinter yet..
|
|
|
|
|
|
|
|
- various obsolete files were removed, and copyright header updated
|
|
|
|
|
|
|
|
- finally updated the standard raster to fix the monochrome rendering bug
|
|
|
|
+ re-enable support for 5-gray levels anti-aliasing (suck, suck..)
|
|
|
|
|
|
|
|
- created new header files, and modified sources accordingly:
|
2000-05-17 01:44:38 +02:00
|
|
|
|
2000-05-17 01:26:01 +02:00
|
|
|
<freetype/fttypes.h> - simple FreeType types, without the API
|
|
|
|
<freetype/internal/ftmemory.h> - definition of memory-management macros
|
|
|
|
|
|
|
|
- added the "DSIG" (OpenType Digital Signature) tag to <freetype/tttags.h>
|
|
|
|
|
2000-05-12 17:01:18 +02:00
|
|
|
- light update/cleaning of the build system + changes to the sources in
|
|
|
|
order to get rid of _all_ compiler warnings with three compilers, i.e:
|
|
|
|
|
|
|
|
gcc with "-ansi -pedantic -Wall -W", Visual C++ with "/W3 /WX"
|
|
|
|
and LCC
|
|
|
|
|
|
|
|
IMPORTANT NOTE FOR WIN32-LCC USERS:
|
|
|
|
|
|
|
|
|
| It seems the C pre-processor that comes with LCC is broken, it
|
|
|
|
| doesn't recognize the ANSI standard directives # and ## correctly
|
|
|
|
| when one of the argument is a macro. Also, something like:
|
2000-05-17 01:44:38 +02:00
|
|
|
|
|
2000-05-12 17:01:18 +02:00
|
|
|
| #define F(x) print##x
|
2000-05-17 01:44:38 +02:00
|
|
|
|
|
2000-05-12 17:01:18 +02:00
|
|
|
| F(("hello"))
|
2000-05-17 01:44:38 +02:00
|
|
|
|
|
2000-05-12 17:01:18 +02:00
|
|
|
| will get incorrectly translated to:
|
2000-05-17 01:44:38 +02:00
|
|
|
|
|
2000-05-12 17:01:18 +02:00
|
|
|
| print "hello")
|
2000-05-17 01:44:38 +02:00
|
|
|
|
|
2000-05-12 17:01:18 +02:00
|
|
|
| by its pre-processor. For this reason, you simply cannot build
|
|
|
|
| FreeType 2 in debug mode with this compiler..
|
|
|
|
|
|
|
|
|
2000-05-12 14:17:15 +02:00
|
|
|
- yet another massive grunt work. I've changed the definition of the
|
|
|
|
EXPORT_DEF, EXPORT_FUNC, BASE_DEF & BASE_FUNC macros. These now take
|
|
|
|
an argument, which is the function's return value type.
|
2000-05-17 01:44:38 +02:00
|
|
|
|
2000-05-12 14:17:15 +02:00
|
|
|
This is necessary to compile FreeType as a DLL on Windows and OS/2.
|
|
|
|
Depending on the compiler used, a compiler-specific keyword like __export
|
|
|
|
or __system must be placed before (VisualC++) or after (BorlandC++)
|
|
|
|
the type..
|
2000-05-17 01:44:38 +02:00
|
|
|
|
2000-05-12 14:17:15 +02:00
|
|
|
Of course, this needed a lot of changes throughout the source code
|
|
|
|
to make it compile again... All cleaned up now, apparently..
|
|
|
|
|
|
|
|
Note also that there is a new EXPORT_VAR macro defined to allow the
|
|
|
|
_declaration_ of an exportable public (constant) variable. This is the
|
|
|
|
case of the raster interfaces (see ftraster.h and ftgrays.h), as well
|
|
|
|
as each module's interface (see sfdriver.h, psdriver.h, etc..)
|
|
|
|
|
|
|
|
- new feature: it is now possible to pass extra parameters to font
|
|
|
|
drivers when creating a new face object. For now, this
|
|
|
|
capability is unused. It could however prove to be useful
|
|
|
|
in a near future..
|
|
|
|
|
|
|
|
the FT_Open_Args structure was changes, as well as the internal
|
|
|
|
driver interface (the specific "init_face" module function has now
|
|
|
|
a different signature).
|
|
|
|
|
|
|
|
- updated the tutorial (not finished though).
|
2000-05-12 17:01:18 +02:00
|
|
|
- updated the top-level BUILD document
|
2000-05-12 14:17:15 +02:00
|
|
|
|
2000-05-12 17:26:58 +02:00
|
|
|
- fixed a potential memory leak that could occur when loading embedded
|
|
|
|
bitmaps.
|
|
|
|
|
2000-05-12 14:17:15 +02:00
|
|
|
- added the declaration of FT_New_Memory_Face in <freetype/freetype.h>, as
|
|
|
|
it was missing from the public header (the implementation was already
|
|
|
|
in "ftobjs.c").
|
|
|
|
|
|
|
|
- the file <freetype/fterrors.h> has been seriously updated in order to
|
|
|
|
allow the automatic generation of error message tables. See the comments
|
|
|
|
within it for more information.
|
|
|
|
|
2000-05-11 20:36:19 +02:00
|
|
|
- major directory hierarchy re-organisation. This was done for two things:
|
2000-05-17 01:44:38 +02:00
|
|
|
|
2000-05-11 20:36:19 +02:00
|
|
|
* first, to ease the "manual" compilation of the library by requiring
|
|
|
|
at lot less include paths :-)
|
2000-05-12 14:17:15 +02:00
|
|
|
|
2000-05-11 20:36:19 +02:00
|
|
|
* second, to allow external programs to effectively access internal
|
|
|
|
data fields. For example, this can be extremely useful if someone
|
|
|
|
wants to write a font producer or a font manager on top of FreeType.
|
|
|
|
|
|
|
|
Basically, you should now use the 'freetype/' prefix for header inclusion,
|
|
|
|
as in:
|
2000-05-17 01:44:38 +02:00
|
|
|
|
2000-05-11 20:36:19 +02:00
|
|
|
#include <freetype/freetype.h>
|
|
|
|
#include <freetype/ftglyph.h>
|
|
|
|
|
|
|
|
Some new include sub-directories are available:
|
2000-05-17 01:44:38 +02:00
|
|
|
|
2000-05-11 20:36:19 +02:00
|
|
|
a. the "freetype/config" directory, contains two files used to
|
|
|
|
configure the build of the library. Client applications should
|
|
|
|
not need to look at these normally, but they can if they want.
|
2000-05-17 01:44:38 +02:00
|
|
|
|
2000-05-11 20:36:19 +02:00
|
|
|
#include <freetype/config/ftoption.h>
|
|
|
|
#include <freetype/config/ftconfig.h>
|
2000-05-17 01:44:38 +02:00
|
|
|
|
2000-05-11 20:36:19 +02:00
|
|
|
b. the "freetype/internal" directory, contains header files that
|
|
|
|
describes library internals. These are the header files that were
|
|
|
|
previously found in the "src/base" and "src/shared" directories.
|
|
|
|
|
|
|
|
|
|
|
|
As usual, the build system and the demos have been updated to reflect
|
|
|
|
the change..
|
2000-05-17 01:44:38 +02:00
|
|
|
|
2000-05-11 20:36:19 +02:00
|
|
|
Here's a layout of the new directory hierarchy:
|
2000-05-17 01:44:38 +02:00
|
|
|
|
2000-05-11 20:36:19 +02:00
|
|
|
TOP
|
|
|
|
include/
|
|
|
|
freetype/
|
|
|
|
freetype.h
|
|
|
|
...
|
|
|
|
config/
|
|
|
|
ftoption.h
|
|
|
|
ftconfig.h
|
|
|
|
ftmodule.h
|
2000-05-17 01:44:38 +02:00
|
|
|
|
2000-05-11 20:36:19 +02:00
|
|
|
internal/
|
|
|
|
ftobjs.h
|
|
|
|
ftstream.h
|
|
|
|
ftcalc.h
|
|
|
|
...
|
2000-05-17 01:44:38 +02:00
|
|
|
|
2000-05-11 20:36:19 +02:00
|
|
|
src/
|
|
|
|
base/
|
|
|
|
...
|
2000-05-17 01:44:38 +02:00
|
|
|
|
2000-05-11 20:36:19 +02:00
|
|
|
sfnt/
|
|
|
|
psnames/
|
|
|
|
truetype/
|
|
|
|
type1/
|
|
|
|
type1z/
|
|
|
|
|
|
|
|
|
|
|
|
Compiling a module is now much easier, for example, the following should
|
2000-05-17 01:26:01 +02:00
|
|
|
work when in the TOP directory on an ANSI build:
|
2000-05-17 01:44:38 +02:00
|
|
|
|
2000-05-11 20:36:19 +02:00
|
|
|
gcc -c -I./include -I./src/base src/base/ftbase.c
|
|
|
|
gcc -c -I./include -I./src/sfnt src/sfnt/sfnt.c
|
|
|
|
etc..
|
|
|
|
|
|
|
|
(of course, using -Iconfig/<system> if you provide system-specific
|
|
|
|
configuration files).
|
2000-05-11 20:23:52 +02:00
|
|
|
|
|
|
|
|
|
|
|
- updated the structure of FT_Outline_Funcs in order to allow
|
|
|
|
direct coordinate scaling within the outline decomposition routine
|
|
|
|
(this is important for virtual "on" points with TrueType outlines)
|
|
|
|
+ updates to the rasters to support this..
|
|
|
|
|
|
|
|
- updated the OS/2 table loading code in "src/sfnt/ttload.c" in order
|
|
|
|
to support version 2 of the table (see OpenType 1.2 spec)
|
|
|
|
|
|
|
|
- created "include/tttables.h" and "include/t1tables.h" to allow
|
|
|
|
client applications to access some of the SFNT and T1 tables of a
|
|
|
|
face with a procedural interface (see FT_Get_Sfnt_Table())
|
|
|
|
+ updates to internal source files to reflect the change..
|
|
|
|
|
|
|
|
- some cleanups in the source code to get rid of warnings when compiling
|
|
|
|
with the "-Wall -W -ansi -pedantic" options in gcc.
|
|
|
|
|
|
|
|
- debugged and moved the smooth renderer to "src/base/ftgrays.c" and
|
|
|
|
its header to "include/ftgrays.h"
|
|
|
|
|
|
|
|
- updated TT_MAX_SUBGLYPHS to 96 as some CJK fonts have composites with
|
|
|
|
up to 80 sub-glyphs !! Thanks to Werner
|
|
|
|
|
|
|
|
================================================================================
|
|
|
|
OLD CHANGES - 14-apr-2000
|
2000-04-14 22:49:52 +02:00
|
|
|
|
|
|
|
- fixed a bug in the TrueType glyph loader that prevented the correct
|
|
|
|
loading of some CJK glyphs in mingli.ttf
|
2000-05-17 01:44:38 +02:00
|
|
|
|
2000-04-14 22:49:52 +02:00
|
|
|
- improved the standard Type 1 hinter in "src/type1"
|
2000-05-17 01:44:38 +02:00
|
|
|
|
2000-04-14 22:49:52 +02:00
|
|
|
- fixed two bugs in the experimental Type 1 driver in "src/type1z"
|
|
|
|
to handle the new XFree86 4.0 fonts (and a few other ones..)
|
|
|
|
|
|
|
|
- the smooth renderer is now complete and supports sub-banding
|
|
|
|
to render large glyphs at high speed. However, it is still located
|
|
|
|
in "demos/src/ftgrays.c" and should move to the library itself
|
|
|
|
in the next beta.. NOTE: The smooth renderer doesn't compile in
|
|
|
|
stand-alone mode anymore, but this should be fixed RSN..
|
2000-05-17 01:44:38 +02:00
|
|
|
|
2000-04-14 22:49:52 +02:00
|
|
|
- introduced convenience functions to more easily deal with glyph
|
|
|
|
images, see "include/ftglyph.h" for more details, as well as the
|
|
|
|
new demo program named "demos/src/ftstring.c" that demonstrates
|
|
|
|
its use
|
|
|
|
|
|
|
|
- implemented FT_LOAD_NO_RECURSE in both the TrueType and Type 1
|
|
|
|
drivers (this is required by the auto-hinter to improve its results).
|
|
|
|
|
|
|
|
- changed the raster interface, in order to allow client applications
|
|
|
|
to provide their own span-drawing callbacks. However, only the
|
|
|
|
smooth renderer supports this. See "FT_Raster_Params" in the
|
|
|
|
file "include/ftimage.h"
|
|
|
|
|
|
|
|
- fixed a small bug in FT_MulFix that caused incorrect transform
|
|
|
|
computation !!
|
|
|
|
|
|
|
|
- Note: The tutorial is out-of-date, grumpf.. :-(
|
|
|
|
|
|
|
|
================================================================================
|
|
|
|
OLD CHANGES - 12-mar-2000
|
2000-03-13 15:19:31 +01:00
|
|
|
|
|
|
|
- changed the layout of configuration files : now, all ANSI configuration
|
|
|
|
files are located in "freetype2/config". System-specific over-rides
|
|
|
|
can be placed in "freetype2/config/<system>".
|
2000-05-17 01:44:38 +02:00
|
|
|
|
2000-03-13 15:19:31 +01:00
|
|
|
- moved all configuration macros to "config/ftoption.h"
|
2000-05-17 01:44:38 +02:00
|
|
|
|
2000-03-13 15:19:31 +01:00
|
|
|
- improvements in the Type 1 driver with AFM support
|
2000-05-17 01:44:38 +02:00
|
|
|
|
2000-03-13 15:19:31 +01:00
|
|
|
- changed the fields in the FT_Outline structure : the old "flags"
|
|
|
|
array is re-named "tags", while all ancient flags are encoded into
|
|
|
|
a single unsigned int named "flags".
|
|
|
|
|
|
|
|
- introduced new flags in FT_Outline.flags (see ft_outline_.... enums in
|
|
|
|
"ftimage.h").
|
|
|
|
|
|
|
|
- changed outline functions to "FT_Outline_<action>" syntax
|
|
|
|
|
|
|
|
- added a smooth anti-alias renderer to the demonstration programs
|
|
|
|
- added Mac graphics driver (thanks Just)
|
2000-05-17 01:44:38 +02:00
|
|
|
|
2000-03-13 15:19:31 +01:00
|
|
|
- FT_Open_Face changed in order to received a pointer to a FT_Open_Args
|
|
|
|
descriptor..
|
2000-05-17 01:44:38 +02:00
|
|
|
|
2000-03-13 15:19:31 +01:00
|
|
|
- various cleanups, a few more API functions implemented (see FT_Attach_File)
|
|
|
|
|
|
|
|
- updated some docs
|
|
|
|
|
|
|
|
================================================================================
|
|
|
|
OLD CHANGES - 22-feb-2000
|
2000-02-22 15:31:42 +01:00
|
|
|
|
|
|
|
- introduced the "psnames" module. It is used to:
|
|
|
|
|
|
|
|
o convert a Postscript glyph name into the equivalent Unicode
|
|
|
|
character code (used by the Type 1 driver(s) to synthetize
|
|
|
|
on the fly a Unicode charmap).
|
|
|
|
|
|
|
|
o provide an interface to retrieve the Postscript names of
|
|
|
|
the Macintosh, Adobe Standard & Adobe Expert character codes.
|
|
|
|
(the Macintosh names are used by the SFNT-module postscript
|
|
|
|
names support routines, while the other two tables are used
|
|
|
|
by the Type 1 driver(s)).
|
|
|
|
|
|
|
|
- introduced the "type1z" alternate Type 1 driver. This is a (still
|
|
|
|
experimental) driver for the Type 1 format that will ultimately
|
|
|
|
replace the one in "src/type1". It uses pattern matching to load
|
|
|
|
data from the font, instead of a finite state analyzer. It works
|
|
|
|
much better than the "old" driver with "broken" fonts. It is also
|
|
|
|
much smaller (under 15 Kb).
|
|
|
|
|
|
|
|
- the Type 1 drivers (both in "src/type1" and "src/type1z") are
|
|
|
|
nearly complete. They both provide automatic Unicode charmap
|
|
|
|
synthesis through the "psnames" module. No re-encoding vector
|
|
|
|
is needed. (note that they still leak memory due to some code
|
|
|
|
missing, and I'm getting lazy).
|
|
|
|
|
|
|
|
Trivial AFM support has been added to read kerning information
|
|
|
|
but wasn't exactly tested as it should ;-)
|
|
|
|
|
|
|
|
- The TrueType glyph loader has been seriously rewritten (see the
|
|
|
|
file "src/truetype/ttgload.c". It is now much, much simpler as
|
|
|
|
well as easier to read, maintain and understand :-) Preliminary
|
|
|
|
versions introduced a memory leak that has been reported by Jack
|
|
|
|
Davis, and is now fixed..
|
|
|
|
|
|
|
|
- introduced the new "ft_glyph_format_plotter", used to represent
|
|
|
|
stroked outlines like Windows "Vector" fonts, and certain Type 1
|
|
|
|
fonts like "Hershey". The corresponding raster will be written
|
|
|
|
soon.
|
|
|
|
|
|
|
|
- FT_New_Memory_Face is gone. Likewise, FT_Open_Face has a new
|
|
|
|
interface that uses a structure to describe the input stream,
|
|
|
|
the driver (if required), etc..
|
|
|
|
|
|
|
|
TODO
|
|
|
|
- Write FT_Get_Glyph_Bitmap and FT_Load_Glyph_Bitmap
|
|
|
|
|
|
|
|
- Add a function like FT_Load_Character( face, char_code, load_flags )
|
|
|
|
that would really embbed a call to FT_Get_Char_Index then FT_Load_Glyph
|
|
|
|
to ease developer's work.
|
|
|
|
|
|
|
|
- Update the tutorial !!
|
|
|
|
- consider adding support for Multiple Master fonts in the Type 1
|
|
|
|
drivers.
|
|
|
|
|
|
|
|
- Test the AFM routines of the Type 1 drivers to check that kerning
|
|
|
|
information is returned correctly.
|
|
|
|
|
|
|
|
- write a decent auto-gridding component !! We need this to release
|
|
|
|
FreeType 2.0 gold !
|
|
|
|
|
|
|
|
|
|
|
|
----- less urgent needs : ----------
|
|
|
|
- add a CFF/Type2 driver
|
|
|
|
- add a BDF driver
|
|
|
|
- add a FNT/PCF/HBF driver
|
|
|
|
- add a Speedo driver from the X11 sources
|
|
|
|
|
|
|
|
|
|
|
|
==============================================================================
|
|
|
|
OLDER CHANGES - 27-jan-2000
|
2000-01-27 15:07:33 +01:00
|
|
|
|
|
|
|
- updated the "sfnt" module interface to allow several SFNT-based
|
|
|
|
drivers to co-exist peacefully
|
2000-05-17 01:44:38 +02:00
|
|
|
|
2000-01-27 15:07:33 +01:00
|
|
|
- updated the "T1_Face" type to better separate Postscript font content
|
|
|
|
from the rest of the FT_Face structure. Might be used later by the
|
|
|
|
CFF/Type2 driver..
|
2000-05-17 01:44:38 +02:00
|
|
|
|
2000-01-27 15:07:33 +01:00
|
|
|
- added an experimental replacement Type 1 driver featuring advanced
|
|
|
|
(and speedy) pattern matching to retrieve the data from postscript
|
|
|
|
fonts.
|
|
|
|
|
|
|
|
- very minor changes in the implementation of FT_Set_Char_Size and
|
|
|
|
FT_Set_Pixel_Sizes (they now implement default to ligthen the
|
|
|
|
font driver's code).
|
|
|
|
|
|
|
|
|
|
|
|
=============================================================================
|
|
|
|
OLD MESSAGE
|
|
|
|
|
1999-12-17 00:11:37 +01:00
|
|
|
This file summarizes the changes that occured since the last "beta" of FreeType 2.
|
|
|
|
Because the list is important, it has been divided into separate sections:
|
|
|
|
|
1999-12-29 01:53:44 +01:00
|
|
|
Table Of Contents:
|
|
|
|
|
|
|
|
I High-Level Interface (easier !)
|
|
|
|
II Directory Structure
|
|
|
|
III Glyph Image Formats
|
|
|
|
IV Build System
|
|
|
|
V Portability
|
|
|
|
VI Font Drivers
|
1999-12-17 00:11:37 +01:00
|
|
|
|
|
|
|
-----------------------------------------------------------------------------------------
|
|
|
|
High-Level Interface :
|
|
|
|
|
|
|
|
The high-level API has been considerably simplified. Here is how :
|
|
|
|
|
1999-12-29 01:53:44 +01:00
|
|
|
- resource objects have disappeared. this means that face objects can
|
|
|
|
now be created with a single function call (see FT_New_Face and
|
1999-12-17 00:11:37 +01:00
|
|
|
FT_Open_Face)
|
2000-05-17 01:44:38 +02:00
|
|
|
|
1999-12-17 00:11:37 +01:00
|
|
|
- when calling either FT_New_Face & FT_Open_Face, a size object and a
|
|
|
|
glyph slot object are automatically created for the face, and can be
|
|
|
|
accessed through "face->glyph" and "face->size" if one really needs to.
|
|
|
|
In most cases, there's no need to call FT_New_Size or FT_New_Glyph.
|
2000-05-17 01:44:38 +02:00
|
|
|
|
1999-12-17 00:11:37 +01:00
|
|
|
- similarly, FT_Load_Glyph now only takes a "face" argument (instead of
|
|
|
|
a glyph slot and a size). Also, it's "result" parameter is gone, as
|
|
|
|
the glyph image type is returned in the field "face->glyph.format"
|
2000-05-17 01:44:38 +02:00
|
|
|
|
1999-12-17 00:11:37 +01:00
|
|
|
- the list of available charmaps is directly accessible through
|
|
|
|
"face->charmaps", counting "face->num_charmaps" elements. Each
|
|
|
|
charmap has an 'encoding' field which specifies which known encoding
|
|
|
|
it deals with. Valid values are, for example :
|
2000-05-17 01:44:38 +02:00
|
|
|
|
1999-12-17 00:11:37 +01:00
|
|
|
ft_encoding_unicode (for ASCII, Latin-1 and Unicode)
|
|
|
|
ft_encoding_apple_roman
|
|
|
|
ft_encoding_sjis
|
|
|
|
ft_encoding_adobe_standard
|
1999-12-29 01:53:44 +01:00
|
|
|
ft_encoding_adobe_expert
|
2000-05-17 01:44:38 +02:00
|
|
|
|
1999-12-17 00:11:37 +01:00
|
|
|
other values may be added in the future. Each charmap still holds its
|
|
|
|
"platform_id" and "encoding_id" values in case the encoding is too
|
|
|
|
exotic for the current library
|
|
|
|
|
|
|
|
|
|
|
|
-----------------------------------------------------------------------------------------
|
|
|
|
Directory Structure:
|
|
|
|
|
|
|
|
Should seem obvious to most of you:
|
|
|
|
|
|
|
|
freetype/
|
|
|
|
config/ -- configuration sub-makefiles
|
|
|
|
ansi/
|
1999-12-29 01:53:44 +01:00
|
|
|
unix/ -- platform-specific configuration files
|
1999-12-17 00:11:37 +01:00
|
|
|
win32/
|
|
|
|
os2/
|
|
|
|
msdos/
|
|
|
|
|
|
|
|
include/ -- public header files, those to be included directly
|
|
|
|
by client apps
|
|
|
|
|
|
|
|
src/ -- sources of the library
|
|
|
|
base/ -- the base layer
|
|
|
|
sfnt/ -- the sfnt "driver" (see the drivers section below)
|
|
|
|
truetype/ -- the truetype driver
|
|
|
|
type1/ -- the type1 driver
|
|
|
|
shared/ -- some header files shared between drivers
|
|
|
|
|
|
|
|
demos/ -- demos/tools
|
|
|
|
|
|
|
|
docs/ -- documentation (a bit empty for now)
|
|
|
|
|
|
|
|
-----------------------------------------------------------------------------------------
|
|
|
|
Glyph Image Formats :
|
|
|
|
|
|
|
|
Drivers are now able to register new glyph image formats within the library.
|
|
|
|
For now, the base layer supports of course bitmaps and vector outlines, but
|
|
|
|
one could imagine something different like colored bitmaps, bi-color
|
|
|
|
vectors or wathever else (Metafonts anyone ??).
|
|
|
|
|
|
|
|
See the file `include/ftimage.h'. Note also that the type FT_Raster_Map is
|
|
|
|
gone, and is now replaced by FT_Bitmap, which should encompass all known
|
|
|
|
bitmap types.
|
|
|
|
|
|
|
|
Each new image format must provide at least one "raster", i.e. a module
|
1999-12-29 01:53:44 +01:00
|
|
|
capable of transforming the glyph image into a bitmap. It's also possible
|
1999-12-17 00:11:37 +01:00
|
|
|
to change the default raster used for a given glyph image format.
|
|
|
|
|
|
|
|
The default outline scan-converter now uses 128 levels of grays by default,
|
|
|
|
which tends to smooth many things. Note that the demo programs have been
|
1999-12-29 01:53:44 +01:00
|
|
|
updated significantly in order to display these..
|
1999-12-17 00:11:37 +01:00
|
|
|
|
|
|
|
|
|
|
|
-----------------------------------------------------------------------------------------
|
|
|
|
Build system :
|
|
|
|
|
|
|
|
You still need GNU Make to build the library. The build system has been
|
|
|
|
very seriously re-vamped in order to provide things like :
|
|
|
|
|
|
|
|
- automatic host platform detection (reverting to 'config/ansi'
|
|
|
|
if it is not detected, with pseudo-standard compilation flags)
|
|
|
|
|
|
|
|
- the ability to compile from the Makefiles with very different and
|
|
|
|
exotic compilers. Note that linking the library can be difficult for
|
|
|
|
some platforms.
|
|
|
|
|
|
|
|
For example, the file `config/win32/lcclib.bat' is invoked by the
|
|
|
|
build system to create the ".lib" file with LCC-Win32 because its
|
|
|
|
librarian has too many flaws to be invoked directly from the Makefile.
|
|
|
|
|
|
|
|
Here's how it works :
|
|
|
|
|
|
|
|
- the first time you type `make', the build system runs a series of
|
|
|
|
sub-makefiles in order to detect your host platform. It then dumps
|
|
|
|
what it found, and creates a file called `config.mk' in the current
|
|
|
|
directory. This is a sub-Makefile used to define many important Make
|
|
|
|
variables used to build the library.
|
|
|
|
|
|
|
|
- the second time, the build system detects the `config.mk' then use it
|
|
|
|
to build the library. All object files go into 'obj' by default, as
|
|
|
|
well as the library file, but this can easily be changed.
|
|
|
|
|
|
|
|
Note that you can run "make setup" to force another host platform detection
|
|
|
|
even if a `config.mk' is present in the current directory. Another solution
|
|
|
|
is simply to delete the file, then re-run make.
|
|
|
|
|
|
|
|
Finally, the default compiler for all platforms is gcc (for now, this will
|
|
|
|
hopefully changed in the future). You can however specify a different
|
|
|
|
compiler by specifying it after the 'setup' target as in :
|
|
|
|
|
|
|
|
gnumake setup lcc on Win32 to use the LCC compiler
|
|
|
|
gnumake setup visualc on Win32 to use Visual C++
|
|
|
|
|
|
|
|
See the file `config/<system>/detect.mk' for a list of supported compilers
|
|
|
|
for your platforms.
|
|
|
|
|
|
|
|
It should be relatively easy to write new detection rules files and
|
|
|
|
config.mk..
|
|
|
|
|
|
|
|
Finally, to build the demo programs, go to `demos' and launch GNU Make,
|
|
|
|
it will use the `config.mk' in the top directory to build the test
|
|
|
|
programs..
|
|
|
|
|
|
|
|
-----------------------------------------------------------------------------------------
|
|
|
|
Portability :
|
|
|
|
|
|
|
|
In the previous beta, a single FT_System object was used to encompass
|
|
|
|
all low-level operations like thread synchronisation, memory management
|
|
|
|
and i/o access. This has been greatly simplified :
|
|
|
|
|
|
|
|
- thread synchronisation has been dropped, for the simple reason that
|
|
|
|
the library is already re-entrant, and that if you really need two
|
|
|
|
threads accessing the same FT_Library, you should really synchronize
|
|
|
|
access to it yourself with a simple mutex.
|
|
|
|
|
|
|
|
- memory management is performed through a very simple object called
|
|
|
|
"FT_Memory", which really is a table containing a table of pointers
|
|
|
|
to functions like malloc, realloc and free as well as some user data
|
|
|
|
(closure).
|
|
|
|
|
|
|
|
- resources have disappeared (they created more problems than they
|
|
|
|
solved), and i/o management have been simplified greatly as a
|
|
|
|
result. Streams are defined through FT_Stream objects, which can
|
|
|
|
be either memory-based or disk-based.
|
|
|
|
|
|
|
|
Note that each face has its own stream, which is closed only when
|
|
|
|
the face object is destroyed. Hence, a function like TT_Flush_Face
|
|
|
|
in 1.x cannot be directly supported. However, if you really need
|
|
|
|
something like this, you can easily tailor your own streams to achieve
|
|
|
|
the same feature at a lower level (and use FT_Open_Face instead of
|
|
|
|
FT_New_Face to create the face).
|
|
|
|
|
|
|
|
See the file "include/ftsystem.h" for more details, as well as the
|
|
|
|
implementations found in "config/unix" and "config/ansi".
|
|
|
|
|
|
|
|
|
|
|
|
-----------------------------------------------------------------------------------------
|
1999-12-29 01:53:44 +01:00
|
|
|
Font Drivers :
|
2000-05-17 01:44:38 +02:00
|
|
|
|
1999-12-29 01:53:44 +01:00
|
|
|
|
|
|
|
The Font Driver interface has been modified in order to support
|
|
|
|
extensions & versioning.
|
|
|
|
|
|
|
|
|
|
|
|
The list of the font drivers that are statically linked to the
|
|
|
|
library at compile time is managed through a new configuration file
|
|
|
|
called `config/<platform>/ftmodule.h'.
|
|
|
|
|
|
|
|
This file is autogenerated when invoking `make modules'. This target
|
|
|
|
will parse all sub-directories of 'src', looking for a "module.mk"
|
|
|
|
rules file, used to describe the driver to the build system.
|
|
|
|
|
|
|
|
Hence, one should call `make modules' each time a font driver is added
|
|
|
|
or removed from the `src' directory.
|
|
|
|
|
|
|
|
|
|
|
|
Finally, this version provides a "pseudo-driver" in `src/sfnt'. This
|
|
|
|
driver doesn't support font files directly, but provides services used
|
|
|
|
by all TrueType-like font drivers. Hence, its code is shared between
|
|
|
|
the TrueType & OpenType font formats, and possibly more formats to
|
|
|
|
come if we're lucky..
|
1999-12-17 00:11:37 +01:00
|
|
|
|
|
|
|
-----------------------------------------------------------------------------------------
|
|
|
|
Extensions support :
|
1999-12-29 01:53:44 +01:00
|
|
|
|
|
|
|
The extensions support is inspired by the one found in 1.x.
|
|
|
|
|
|
|
|
Now, each font driver has its own "extension registry", which lists
|
|
|
|
which extensions are available for the font faces managed by the driver.
|
|
|
|
|
|
|
|
Extension ids are now strings, rather than 4-byte tags, as this is
|
|
|
|
usually more readable..
|
|
|
|
|
|
|
|
Each extension has:
|
|
|
|
- some data, associated to each face object
|
|
|
|
- an interface (table of function pointers)
|
|
|
|
|
|
|
|
An extension that is format-specific should simply register itself
|
|
|
|
to the correct font driver. Here is some example code:
|
|
|
|
|
|
|
|
// Registering an extensions
|
|
|
|
//
|
|
|
|
FT_Error FT_Init_XXXX_Extension( FT_Library library )
|
|
|
|
{
|
|
|
|
FT_DriverInterface* tt_driver;
|
|
|
|
|
|
|
|
driver = FT_Get_Driver( library, "truetype" );
|
|
|
|
if (!driver) return FT_Err_Unimplemented_Feature;
|
|
|
|
|
2000-05-17 01:44:38 +02:00
|
|
|
return FT_Register_Extension( driver, &extension_class );
|
1999-12-29 01:53:44 +01:00
|
|
|
}
|
|
|
|
|
2000-05-17 01:44:38 +02:00
|
|
|
|
1999-12-29 01:53:44 +01:00
|
|
|
// Implementing the extensions
|
|
|
|
//
|
|
|
|
FT_Error FT_Proceed_Extension_XXX( FT_Face face )
|
|
|
|
{
|
|
|
|
FT_XXX_Extension ext;
|
|
|
|
FT_XXX_Extension_Interface ext_interface;
|
|
|
|
|
|
|
|
ext = FT_Get_Extension( face, "extensionid", &ext_interface );
|
|
|
|
if (!ext) return error;
|
|
|
|
|
|
|
|
return ext_interface->do_it(ext);
|
|
|
|
}
|
1999-12-17 00:11:37 +01:00
|
|
|
|