ref: ab6d10759a8f5f3a4987aeff9e0bd7d79d529c82
parent: 8f031b08ec0cd21d530ac588896ee9fe32c569bd
author: Werner Lemberg <[email protected]>
date: Mon Apr 2 17:30:06 EDT 2001
* CHANGES: Reformatted, minor fixes. * TODO: Updated. * include/freetype/freetype.h: Formatting. * Jamrules, Jamfile, src/Jamfile, src/*/Jamfile: Adding jamfiles to the source tree. See www.freetype.org/jam/index.html for details.
--- a/CHANGES
+++ b/CHANGES
@@ -4,533 +4,515 @@
I. CHANGES TO THE MODULES / FONT DRIVERS:
- THE TRUETYPE BYTECODE INTERPRETER IS NOW TURNED OFF, in order to
- avoid legal problems with the Apple patents. It seems that we
- mistakenly turned this option on in previous releases of the build.
-
- note that if you want to use the bytecode interpreter, in order to
- get high-quality TrueType rendering, you'll need to toggle by hand
- the definition of the TT_CONFIG_OPTION_BYTECODE_INTERPRETER macro
- in the file "include/freetype/config/ftoption.h"
+ avoid legal problems with the Apple patents. It seems that we
+ mistakenly turned this option on in previous releases of the
+ build.
- - The CFF driver has been improved by Tom Kacvinsky and Sander van der Wal:
-
- * support for "seac" emulation
- * support for "dotsection"
- * support for retrieving glyph names through "FT_Get_Glyph_Name"
+ Note that if you want to use the bytecode interpreter in order
+ to get high-quality TrueType rendering, you will need to toggle
+ by hand the definition of the
+ TT_CONFIG_OPTION_BYTECODE_INTERPRETER macro in the file
+ "include/freetype/config/ftoption.h".
- The first two items are necessary to correctly a large number of
- Type 1 fonts converted to the CFF formats by Adobe Acrobat.
+ - The CFF driver has been improved by Tom Kacvinsky and Sander van
+ der Wal:
+ * Support for "seac" emulation.
+ * Support for "dotsection".
+ * Support for retrieving glyph names through
+ "FT_Get_Glyph_Name".
- - the Type 1 driver was also improved by Tom & others:
-
- * better EM size computation
-
- * better support for synthetic (transformed) fonts
-
- * the Type 1 driver returns the charstrings corresponding to
- each glyph in the "glyph->control_data" field after a call to
- "FT_Load_Glyph" (thanks Ha Shao)
+ The first two items are necessary to correctly a large number of
+ Type 1 fonts converted to the CFF formats by Adobe Acrobat.
+ - The Type 1 driver was also improved by Tom & others:
- - various other bugfixes, including the following:
-
- * fixed a nasty memory leak in the Type 1 driver
-
- * the autohinter and the pcf driver used static writable data
- when they shouldn't
-
- * many casts were added to make the code more 64-bits safe.
- it also now compiles on Windows XP 64-bits without warnings
+ * Better EM size computation.
+ * Better support for synthetic (transformed) fonts.
+ * The Type 1 driver returns the charstrings corresponding to
+ each glyph in the "glyph->control_data" field after a call to
+ "FT_Load_Glyph" (thanks Ha Shao).
- * some incorrect writable statics were removed in the "autohint"
- and "pcf" drivers. FT2 now compiles on Epoc again..
+ - Various other bugfixes, including the following:
+ * Fixed a nasty memory leak in the Type 1 driver.
+ * The autohinter and the pcf driver used static writable data
+ when they shouldn't.
+ * Many casts were added to make the code more 64-bits safe. It
+ also now compiles on Windows XP 64-bits without warnings.
+ * Some incorrect writable statics were removed in the "autohint"
+ and "pcf" drivers. FreeType 2 now compiles on Epoc again.
+
II. CHANGES TO THE HIGH-LEVEL API
-
- - the library header files inclusion scheme has been changed. The old
- scheme looked like:
-
- #include <freetype/freetype.h>
- #include <freetype/ftglyph.h>
- #include <freetype/ftcache.h>
- #include <freetype/cache/ftimage.h>
-
- use:
-
- #include <ft2build.h>
- #include FT_FREETYPE_H
- #include FT_GLYPH_H
- #include FT_CACHE_H
- #include FT_CACHE_IMAGE_H
-
- NOTE THAT THE OLD INCLUSION SCHEME WILL STILL WORK WITH THIS RELEASE.
- HOWEVER, WE DON'T GUARANTEE THAT THIS WILL STILL BE TRUE IN THE NEXT
- ONE (A.K.A. FREETYPE 2.1)
- the file <ft2build.h> is used to define the header filename macros.
- The complete and commented list of macros is available in the API
- reference under the section name "Header File Macros" in Chapter I.
+ - The library header files inclusion scheme has been changed. The
+ old scheme looked like:
- For more information, see section I of the following document:
-
- http://www.freetype.org/freetype2/docs/tutorial/step1.html
- or http://freetype.sourceforge.net/freetype2/docs/tutorial/step1.html
+ #include <freetype/freetype.h>
+ #include <freetype/ftglyph.h>
+ #include <freetype/ftcache.h>
+ #include <freetype/cache/ftimage.h>
+ Now you should use:
- - many, many comments have been added to the public source file in
- order to automatically generate the API Reference through the
- "docmaker.py" Python script.
-
- The latter has been updated to support the grouping of sections
- in chapters, and better index sort. See:
+ #include <ft2build.h>
+ #include FT_FREETYPE_H
+ #include FT_GLYPH_H
+ #include FT_CACHE_H
+ #include FT_CACHE_IMAGE_H
- http://www.freetype.org/freetype2/docs/reference/ft2-toc.html
+ NOTE THAT THE OLD INCLUSION SCHEME WILL STILL WORK WITH THIS
+ RELEASE. HOWEVER, WE DO NOT GUARANTEE THAT THIS WILL STILL BE
+ TRUE IN THE NEXT ONE (A.K.A. FREETYPE 2.1).
+ The file <ft2build.h> is used to define the header filename
+ macros. The complete and commented list of macros is available
+ in the API reference under the section name "Header File Macros"
+ in Chapter I.
- III. CHANGES TO THE BUILD PROCESS
-
+ For more information, see section I of the following document:
- - if you're not building FreeType 2 with our own build system (i.e. with
- your own Makefiles or project files), you'll need to be aware that the
- build process as changed a little bit. Namely:
-
- - you don't need to put the "src" directory in the include path
- when compiling any FT2 component
-
- - instead, simply put the component's directory in the current
- include path.
-
- So, if you were doing something like:
-
- cc -c -Iinclude -Isrc src/base/ftbase.c
-
- change the line to:
-
- cc -c -Iinclude -Isrc/base src/base/ftbase.c
-
-
- If you were doing something like:
-
- cd src/base
- cc -c -I../../include -I.. ftbase.c
-
- change it to:
-
- cd src/base
- cc -c -I../../include ftbase.c
+ http://www.freetype.org/
+ freetype2/docs/tutorial/step1.html
-
- - the build system has changed slightly when compiling by hand (either
- from the command line or from an IDE). You don't need to put the "src"
- directory in the include path anymore. Rather, place each component's
- path.. See INSTALL and "docs/BUILD" for details..
+ or
+ http://freetype.sourceforge.net/
+ freetype2/docs/tutorial/step1.html
+ - Many, many comments have been added to the public source file in
+ order to automatically generate the API Reference through the
+ "docmaker.py" Python script.
-=========================================================================
-LATEST CHANGES BETWEEN 2.0.1 and 2.0:
+ The latter has been updated to support the grouping of sections
+ in chapters and better index sort. See:
- 2.0.1 introduces a few changes:
+ http://www.freetype.org/freetype2/docs/reference/ft2-toc.html
- - fixed many bugs related to the support of CFF / OpenType fonts.
- These formats are now much better supported though there is still
- work planned to deal with Charset tables and PDF-embedded CFF
- files that use the old "seac" command.
-
- - the library could not be compiled in debug mode with a very small
- number of C compilers whose pre-processors didn't implement the
- "##" directive correctly (i.e. per se the ANSI C specification!)
- An elegant fix was found.
-
- - added support for the free Borland command-line C++ Builder compiler
- use "make setup bcc32" to use it. Also fixed a few source lines that
- generated new warnings with BCC32.
-
- - fixed a bug in FT_Outline_Get_BBox when computing the extrema of
- a conic Bezier arc.
-
- - updated the INSTALL file to add IDE compilation.
- - other minor bug fixes, from invalid Type 1 style flags to correct
- support of synthetic (obliqued) fonts in the auto-hinter, better
- support for embedded bitmaps in a SFNT font.
+ III. CHANGES TO THE BUILD PROCESS
- - fixed some problems with "freetype-config"
+ - If you are not building FreeType 2 with its own build system
+ (but with your own Makefiles or project files), you will need to
+ be aware that the build process has changed a little bit.
- Finally, the "standard" scheme for including FreeType headers is now
- gradually changing, but this will be explained in a later release
- (probably 2.0.2) ...
+ You don't need to put the "src" directory in the include path
+ when compiling any FT2 component. Instead, simply put the
+ component's directory in the current include path.
- And very special thanks to Tom Kacvinsky and YAMANO-UCHI Hidetoshi for
- their contributions!
+ So, if you were doing something like:
-=========================================================================
-CHANGES BETWEEN beta8 and 2.0
+ cc -c -Iinclude -Isrc src/base/ftbase.c
- - changed the default installation path for public headers from
- "include/freetype" to "include/freetype2".
+ change the line to:
- Also added a new "freetype-config" that is automatically
- generated and installed on Unix and Cygwin systems. The
- script itself is used to retrieve the current install path,
- C compilation flags as well as linker flags..
+ cc -c -Iinclude -Isrc/base src/base/ftbase.c
- - fixed several small bugs:
+ If you were doing something like:
- - incorrect max advance width for fixed-pitch Type 1 fonts
+ cd src/base
+ cc -c -I../../include -I.. ftbase.c
- - incorrect glyph names for certain TrueType fonts
+ change it to:
- - the glyph advance was not copied when FT_Glyph_To_Bitmap was called
+ cd src/base
+ cc -c -I../../include ftbase.c
- - the linearHoriAdvance and linerVertAdvance fields were not
- correctly returned for glyphs processed by the auto-hinter
- - "type1z" renamed back to "type1"; the old "type1" module has been
- removed
+======================================================================
- - 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)
+LATEST CHANGES BETWEEN 2.0.1 and 2.0:
- - changed "cid" to use "psaux" too..
- - 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 ..
+ 2.0.1 introduces a few changes:
- - updated "docs/docmaker.py", a draft API reference is available at
- http://www.freetype.org/ft2api.html
+ - Fixed many bugs related to the support of CFF / OpenType fonts.
+ These formats are now much better supported though there is
+ still work planned to deal with charset tables and PDF-embedded
+ CFF files that use the old "seac" command.
- - changed "type1" to use "psaux"
+ - The library could not be compiled in debug mode with a very
+ small number of C compilers whose pre-processors didn't
+ implement the "##" directive correctly (i.e. per se the ANSI C
+ specification!) An elegant fix was found.
- - created a new module named "psaux" to hold the Type 1 & Type 2 parsing
- routines. It should be used by "type1", "cid" and "cff" in the future
+ - Added support for the free Borland command-line C++ Builder
+ compiler. Use "make setup bcc32". Also fixed a few source
+ lines that generated new warnings with BCC32.
- - fixed an important bug in "FT_Glyph_Get_CBox"
+ - Fixed a bug in FT_Outline_Get_BBox when computing the extrema of
+ a conic Bezier arc.
- - fixed some compiler warnings that happened since the TrueType
- bytecode decoder was deactivated by default..
+ - Updated the INSTALL file to add IDE compilation.
- - fixed two memory leaks:
- - the memory manager (16 bytes) isn't released in FT_Done_FreeType !!
+ - Other minor bug fixes, from invalid Type 1 style flags to
+ correct support of synthetic (obliqued) fonts in the
+ auto-hinter, better support for embedded bitmaps in a SFNT font.
- - using custom input streams, the copy of the original stream
- was never released
+ - Fixed some problems with "freetype-config".
- - 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..
+ Finally, the "standard" scheme for including FreeType headers is now
+ gradually changing, but this will be explained in a later release
+ (probably 2.0.2).
-===========================================================================
-BETA-8 (RELEASE CANDIDATE) CHANGES
+ And very special thanks to Tom Kacvinsky and YAMANO-UCHI Hidetoshi
+ for their contributions!
- - deactivated the trueType bytecode interpreter by default
- - deactivated the "src/type1" font driver. Now "src/type1z" is
- used by default..
+======================================================================
- - 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.
+CHANGES BETWEEN beta8 and 2.0
- - added the auto-hinting module !!. Fixing some bugs here and there..
+ - Changed the default installation path for public headers from
+ "include/freetype" to "include/freetype2".
- - found some bugs in the composite loader (seac) of the Type1-based
- font drivers..
+ Also added a new "freetype-config" that is automatically generated
+ and installed on Unix and Cygwin systems. The script itself is
+ used to retrieve the current install path, C compilation flags as
+ well as linker flags.
- - renamed the directory "freetype2/config" to "freetype2/builds" and
- updated all relevant files..
+ - Fixed several small bugs:
- - found a memory leak in the "type1" driver
+ * Incorrect max advance width for fixed-pitch Type 1 fonts.
+ * Incorrect glyph names for certain TrueType fonts.
+ * The glyph advance was not copied when FT_Glyph_To_Bitmap was
+ called.
+ * The linearHoriAdvance and linerVertAdvance fields were not
+ correctly returned for glyphs processed by the auto-hinter.
+ * "type1z" renamed back to "type1"; the old "type1" module has
+ been removed.
- - 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.. :-)
+ - 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).
- - 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..
+ - Changed "cid" to use "psaux" too.
- 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..
+ - 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.
- I'm still working on the PCF/BDF drivers.. but I'm too lazy
- to finish them now..
+ - Updated "docs/docmaker.py", a draft API reference is available at
+ http://www.freetype.org/ft2api.html.
+ - Changed "type1" to use "psaux".
- - CHANGES TO THE HIGH-LEVEL API
+ - Created a new module named "psaux" to hold the Type 1 & Type 2
+ parsing routines. It should be used by "type1", "cid", and "cff"
+ in the future.
- 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 ).
+ - Fixed an important bug in "FT_Glyph_Get_CBox".
- o the outline functions are now in <freetype/ftoutln.h> and not
- part of <freetype/freetype.h> anymore
+ - Fixed some compiler warnings that happened since the TrueType
+ bytecode decoder was deactivated by default.
- o <freetype/ftmodule.h> now contains declarations for
- FT_New_Library, FT_Done_Library, FT_Add_Default_Modules
+ - Fixed two memory leaks:
- 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..
+ * The memory manager (16 bytes) isn't released in
+ FT_Done_FreeType!
+ * Using custom input streams, the copy of the original stream was
+ never released.
- 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.
+ - 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.
- FT_LOAD_ANTI_ALIAS is still defined, but values to 0.
- o <freetype/freetype.h> now include <freetype/config/ftconfig.h>,
- solving a few headaches :-)
+======================================================================
- o the type FT_GlyphSlotRec has now a "library" field.
+BETA-8 (RELEASE CANDIDATE) CHANGES
+ - Deactivated the TrueType bytecode interpreter by default.
+ - Deactivated the "src/type1" font driver. Now "src/type1z" is used
+ by default.
- - CHANGES TO THE "ftglyph.h" API
+ - 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.
- 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.
+ - Added the auto-hinting module! Fixing some bugs here and there.
- - added support for CID-keyed fonts to the CFF driver.
- maybe support for pure CFF + CEF fonts should come in ??
+ - Found some bugs in the composite loader (seac) of the Type1-based
+ font drivers.
+ - Renamed the directory "freetype2/config" to "freetype2/builds" and
+ updated all relevant files.
- - 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.
+ - Found a memory leak in the "type1" driver.
- "make multi" now works well :-)
+ - 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 :-)
- 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..
+ - 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.
+ It is 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.
+ I'm still working on the PCF/BDF drivers, but I'm too lazy to
+ finish them now.
- - ADDED SUPPORT FOR THE AUTO-HINTER
+ - CHANGES TO THE HIGH-LEVEL API
- 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.
+ * FT_Get_Kerning has a new parameter that allows you to select the
+ coordinates of the kerning vector (font units, scaled, scaled +
+ grid-fitted).
+ * The outline functions are now in <freetype/ftoutln.h> and not
+ part of <freetype/freetype.h> anymore.
+ * <freetype/ftmodule.h> now contains declarations for
+ FT_New_Library, FT_Done_Library, FT_Add_Default_Modules.
+ * 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.
+ * 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.
+ FT_LOAD_ANTI_ALIAS is still defined, but values to 0.
+ * <freetype/freetype.h> now include <freetype/config/ftconfig.h>,
+ solving a few headaches :-)
+ * The type FT_GlyphSlotRec has now a "library" field.
- CID fonts are not hinted, as they include no charmap and the auto-hinter
- doesn't include "generic" global metrics computations yet..
+ - CHANGES TO THE "ftglyph.h" API
- Now, I need to release this thing to the FreeType 2 source..
+ 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.
+ - Added support for CID-keyed fonts to the CFF driver. Maybe
+ support for pure CFF + CEF fonts should come in?
+ - 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.
+ "make multi" now works well :-)
+ 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.
- - CHANGES TO THE RENDERER MODULES
+ - ADDED SUPPORT FOR THE AUTO-HINTER
- 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..
+ 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 initialization, and Type
+ 1 & OpenType/CFF fonts are now hinted.
- I ditched the 5-gray-levels renderers. Basically, it involved a simple
- #define toggle in 'src/raster1/ftraster.c'
+ CID fonts are not hinted, as they include no charmap and the
+ auto-hinter doesn't include "generic" global metrics computations
+ yet.
- 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.
+ Now, I need to release this thing to the FreeType 2 source.
- 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..
+ - CHANGES TO THE RENDERER MODULES
- Changed the demo programs accordingly..
+ 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.
+ I ditched the 5-gray-levels renderers. Basically, it involved a
+ simple #define toggle in 'src/raster1/ftraster.c'.
+ 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. 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.
+ Changed the demo programs accordingly.
+
- MAJOR INTERNAL REDESIGN:
- A lot of internal modifications have been performed lately on the
+ A lot of internal modifications have been performed lately on the
source in order to provide the following enhancements:
- - more generic module support:
+ * 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_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..
+ 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:
- - support for generic glyph image types:
+ The FT_Renderer type is a pointer to a module used to perform
+ various operations on glyph image.
- 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:
- 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
- - 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 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.
+ he current renderer can be set through the new function
+ FT_Set_Renderer.
- One corresponds to the "standard" scan-converter, the other to the
- "smooth" one.
+ The old raster-related function FT_Set_Raster, FT_Get_Raster and
+ FT_Set_Raster_Mode have now disappeared, in favor of the new:
- The current renderer can be set through the new function
- FT_Set_Renderer.
+ FT_Get_Renderer
+ 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:
+ See the file <freetype/ftrender.h> for more details.
- FT_Get_Renderer
- FT_Set_Renderer
+ These changes were necessary to properly support different
+ scalable formats in the future, like bi-color glyphs, etc.
- see the file <freetype/ftrender.h> for more details..
+ * Glyph loader object:
- These changes were necessary to properly support different scalable
- formats in the future, like bi-color glyphs, etc..
+ 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.
- - glyph loader object:
+ See <freetype/internal/ftobjs.h> and the FT_GlyphLoader type for
+ more information.
- 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.
+ * FT_GlyphSlot has new fields:
- This object has been created to reduce the code size of each driver,
- as each one of them basically re-implemented its functionality.
+ In order to support extended features (see below), the
+ FT_GlyphSlot structure has a few new fields:
- See <freetype/internal/ftobjs.h> and the FT_GlyphLoader type for
- more information..
+ 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.
- - FT_GlyphSlot had new fields:
+ Note that the two above field replace the removed "metrics2"
+ field in the glyph slot.
- In order to support extended features (see below), the FT_GlyphSlot
- structure has a few new fields:
+ 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.
- 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_left:
+ This field gives the distance in integer pixels from the
+ current pen position to the left-most pixel of a glyph image
+ IF 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.
+ 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 IF 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..
+ 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:
+ * 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:
+ 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..
+ - 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.
- - 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.
+ - Reformatted 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.
- - 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.
+======================================================================
-
-
- - 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
- - 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 :-)
+ - 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 :-)
- fixed the crummy Type 1 hinter, it now handles accented characters
- correctly (well, the accent is not always well placed, but that's
+ correctly (well, the accent is not always well placed, but that's
another problem..)
- - 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..
+ - 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..
+ - fixed two bugs in the smooth renderer (src/base/ftgrays.c). Thanks
+ to Boris Letocha for spotting them and providing a fix..
- fixed potential "divide by zero" bugs in ftcalc.c.. my god..
- - added source code for the OpenType/CFF driver (still incomplete though..)
+ - 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..
+ - 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..
- - 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..)
+ - 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..
- added support for Multiple Master fonts in "type1z". There is also
- a new file named <freetype/ftmm.h> which defines functions to
+ a new file named <freetype/ftmm.h> which defines functions to
manage them from client applications.
The new file "src/base/ftmm.c" is also optional to the engine..
- - various formatting changes (e.g. EXPORT_DEF -> FT_EXPORT_DEF) +
+ - various formatting changes (e.g. EXPORT_DEF -> FT_EXPORT_DEF) +
small bug fixes in FT_Load_Glyph, the "type1" driver, etc..
- a minor fix to the Type 1 driver to let them apply the font matrix
@@ -539,111 +521,122 @@
- some fixes for 64-bit systems (mainly changing some FT_TRACE calls
to use %p instead of %lx).. Thanks to Karl Robillard
- - 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 ??).
+ - 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 ??).
- - 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
- see any difference ;-)
+ - 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 see any difference ;-)
- - removed TT_MAX_SUBGLYPHS, there is no static limit on the number of
- subglyphs in a TrueType font now..
+ - removed TT_MAX_SUBGLYPHS, there is no static limit on the number
+ of subglyphs in a TrueType font now..
-=============================================================================
+
+======================================================================
+
OLD CHANGES 16 May 2000
- - tagged "BETA-6" in the CVS tree. This one is a serious release candidate
- even though it doesn't incorporate the auto-hinter yet..
+ - 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..)
+ - 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:
- <freetype/fttypes.h> - simple FreeType types, without the API
- <freetype/internal/ftmemory.h> - definition of memory-management macros
+ <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>
+ - added the "DSIG" (OpenType Digital Signature) tag to
+ <freetype/tttags.h>
- - 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:
+ - 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
+ 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:
- |
- | #define F(x) print##x
- |
- | F(("hello"))- |
- | will get incorrectly translated to:
- |
- | print "hello")
- |
- | by its pre-processor. For this reason, you simply cannot build
- | FreeType 2 in debug mode with this compiler..
+ 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:
+ |
+ | #define F(x) print##x
+ |
+ | F(("hello"))+ |
+ | will get incorrectly translated to:
+ |
+ | print "hello")
+ |
+ | by its pre-processor. For this reason, you simply cannot build
+ | FreeType 2 in debug mode with this compiler..
-
- 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.
+ EXPORT_DEF, EXPORT_FUNC, BASE_DEF & BASE_FUNC macros. These now
+ take an argument, which is the function's return value type.
- 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..
+ 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..
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..)
+ 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..
+ - 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).
+ 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).
+
- updated the top-level BUILD document
- - fixed a potential memory leak that could occur when loading embedded
- bitmaps.
+ - fixed a potential memory leak that could occur when loading
+ embedded bitmaps.
- - 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").
+ - 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.
+ - 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.
- - major directory hierarchy re-organisation. This was done for two things:
+ - major directory hierarchy re-organisation. This was done for two
+ things:
- * first, to ease the "manual" compilation of the library by requiring
- at lot less include paths :-)
+ * first, to ease the "manual" compilation of the library by
+ requiring at lot less include paths :-)
- * 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.
+ * 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:
+ Basically, you should now use the 'freetype/' prefix for header
+ inclusion, as in:
#include <freetype/freetype.h>
#include <freetype/ftglyph.h>
@@ -650,7 +643,7 @@
Some new include sub-directories are available:
- a. the "freetype/config" directory, contains two files used to
+ 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.
@@ -657,13 +650,14 @@
#include <freetype/config/ftoption.h>
#include <freetype/config/ftconfig.h>
- 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.
+ 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..
+ As usual, the build system and the demos have been updated to
+ reflect the change..
Here's a layout of the new directory hierarchy:
@@ -694,8 +688,8 @@
type1z/
- Compiling a module is now much easier, for example, the following should
- work when in the TOP directory on an ANSI build:
+ Compiling a module is now much easier, for example, the following
+ should work when in the TOP directory on an ANSI build:
gcc -c -I./include -I./src/base src/base/ftbase.c
gcc -c -I./include -I./src/sfnt src/sfnt/sfnt.c
@@ -704,159 +698,172 @@
(of course, using -Iconfig/<system> if you provide system-specific
configuration files).
+ - 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 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)
- - 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..
- - 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.
- - 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
+ - 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
- - fixed a bug in the TrueType glyph loader that prevented the correct
- loading of some CJK glyphs in mingli.ttf
+ - fixed a bug in the TrueType glyph loader that prevented the
+ correct loading of some CJK glyphs in mingli.ttf
- improved the standard Type 1 hinter in "src/type1"
- - fixed two bugs in the experimental Type 1 driver in "src/type1z"
+ - 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
+ - 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..
- - 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
+ - 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).
+ - 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"
+ - 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 !!
+ - 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
- - 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>".
+ - 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>".
- moved all configuration macros to "config/ftoption.h"
- improvements in the Type 1 driver with AFM support
- - changed the fields in the FT_Outline structure : the old "flags"
+ - 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").
+ - 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)
- - FT_Open_Face changed in order to received a pointer to a FT_Open_Args
- descriptor..
+ - FT_Open_Face changed in order to received a pointer to a
+ FT_Open_Args descriptor..
- - various cleanups, a few more API functions implemented (see FT_Attach_File)
+ - various cleanups, a few more API functions implemented (see
+ FT_Attach_File)
- updated some docs
-================================================================================
+
+======================================================================
+
OLD CHANGES - 22-feb-2000
- 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 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)).
+ 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
+ - 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
+ - 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 ;-)
+ 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
+ - 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
+ - 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..
+ - 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.
+ - 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
+ - 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
+ - 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
+ - write a decent auto-gridding component !! We need this to release
FreeType 2.0 gold !
------ less urgent needs : ----------
+less urgent needs:
+
- add a CFF/Type2 driver
- add a BDF driver
- add a FNT/PCF/HBF driver
@@ -863,30 +870,33 @@
- add a Speedo driver from the X11 sources
-==============================================================================
+======================================================================
+
OLDER CHANGES - 27-jan-2000
- - updated the "sfnt" module interface to allow several SFNT-based
+ - updated the "sfnt" module interface to allow several SFNT-based
drivers to co-exist peacefully
- - 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..
+ - 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..
- 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).
+ - 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
-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:
+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:
Table Of Contents:
@@ -897,29 +907,33 @@
V Portability
VI Font Drivers
------------------------------------------------------------------------------------------
-High-Level Interface :
- The high-level API has been considerably simplified. Here is how :
+----------------------------------------------------------------------
- - resource objects have disappeared. this means that face objects can
- now be created with a single function call (see FT_New_Face and
- FT_Open_Face)
+High-Level Interface:
- - 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.
+ The high-level API has been considerably simplified. Here is how:
- - 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"
+ - resource objects have disappeared. this means that face objects
+ can now be created with a single function call (see FT_New_Face
+ and FT_Open_Face)
- - 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 :
+ - 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.
+ - 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"
+
+ - 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 :
+
ft_encoding_unicode (for ASCII, Latin-1 and Unicode)
ft_encoding_apple_roman
ft_encoding_sjis
@@ -926,12 +940,13 @@
ft_encoding_adobe_standard
ft_encoding_adobe_expert
- 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
+ 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:
@@ -944,12 +959,13 @@
os2/
msdos/
- include/ -- public header files, those to be included directly
- by client apps
+ 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)
+ sfnt/ -- the sfnt "driver" (see the drivers section
+ below)
truetype/ -- the truetype driver
type1/ -- the type1 driver
shared/ -- some header files shared between drivers
@@ -958,145 +974,158 @@
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.
+Glyph Image Formats:
- Each new image format must provide at least one "raster", i.e. a module
- capable of transforming the glyph image into a bitmap. It's also possible
- to change the default raster used for a given glyph image format.
+ 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
+ ??).
- 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
- updated significantly in order to display these..
+ 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 capable of transforming the glyph image into a bitmap. It's
+ also possible to change the default raster used for a given glyph
+ image format.
------------------------------------------------------------------------------------------
-Build system :
+ 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 updated significantly in order to display these..
- 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)
+----------------------------------------------------------------------
+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.
+ 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.
+ librarian has too many flaws to be invoked directly from the
+ Makefile.
- Here's how it works :
+ Here's how it works:
- - the first time you type `make', the build system runs a series of
+ - 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.
+ 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.
+ - 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.
+ 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 :
+ 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.
+ 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
+ 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..
+ 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.
+Portability:
- - 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).
+ 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
+ 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).
+ 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
+ See the file "include/ftsystem.h" for more details, as well as the
implementations found in "config/unix" and "config/ansi".
------------------------------------------------------------------------------------------
-Font Drivers :
+----------------------------------------------------------------------
+Font Drivers:
- The Font Driver interface has been modified in order to support
+ 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
+ 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"
+ 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.
+ 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..
+ 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..
------------------------------------------------------------------------------------------
-Extensions support :
+----------------------------------------------------------------------
+
+Extensions support:
+
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.
+ 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
+ Extension ids are now strings, rather than 4-byte tags, as this is
usually more readable..
Each extension has:
@@ -1103,7 +1132,7 @@
- some data, associated to each face object
- an interface (table of function pointers)
- An extension that is format-specific should simply register itself
+ An extension that is format-specific should simply register itself
to the correct font driver. Here is some example code:
// Registering an extensions
@@ -1132,3 +1161,4 @@
return ext_interface->do_it(ext);
}
+--- end of CHANGES ---
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2001-04-02 Werner Lemberg <[email protected]>
+
+ * CHANGES: Reformatted, minor fixes.
+ * TODO: Updated.
+ * include/freetype/freetype.h: Formatting.
+
2001-04-02 Tom Kacvinsky <[email protected]>
* src/sfnt/ttload.c (TT_Load_Metrics): Fix an improper pointer
@@ -11,8 +17,8 @@
2001-03-24 David Turner <[email protected]>
- * Jamrules, Jamfile, src/Jamfile, src/*/Jamfile: Adding jamfiles
- to the source tree. see www.freetype.org/jam/index.html for details
+ * Jamrules, Jamfile, src/Jamfile, src/*/Jamfile: Adding jamfiles to
+ the source tree. See www.freetype.org/jam/index.html for details.
* Version 2.0.2 released.
--- a/TODO
+++ b/TODO
@@ -2,11 +2,13 @@
* Add synthesized Unicode charmap processing to the CFF driver.
-* Fix Visual C++ project file
+* Fix Visual C++ project file.
* Fix a bug in the TrueType driver: linear horizontal advances of composites
are not returned properly.
* Change the build system to work with the "Jam" tool instead of the
- terribly complex and error-prone GNU Makefiles we're currently using
+ terribly complex and error-prone GNU Makefiles we are currently using.
+* Fix exact bbox calculation for cubics. The current code uses an iterative
+ algorithm which can fail miserably.
--- a/include/freetype/freetype.h
+++ b/include/freetype/freetype.h
@@ -822,123 +822,141 @@
/* */
#define FT_FACE_FLAG_EXTERNAL_STREAM 0x4000
+
/* */
- /***********************************************************************
- *
- * @macro: FT_HAS_HORIZONTAL (face)
- *
- * @description:
- * a macro that returns true whenever a face object contains horizontal
- * metrics. (this is true for all font formats though).
- *
- * @also:
- * @FT_HAS_VERTICAL can be used to check for vertical metrics.
- */
+
+ /*************************************************************************/
+ /* */
+ /* @macro: FT_HAS_HORIZONTAL (face) */
+ /* */
+ /* @description: */
+ /* A macro that returns true whenever a face object contains */
+ /* horizontal metrics (this is true for all font formats though). */
+ /* */
+ /* @also: */
+ /* @FT_HAS_VERTICAL can be used to check for vertical metrics. */
+ /* */
#define FT_HAS_HORIZONTAL( face ) \
( face->face_flags & FT_FACE_FLAG_HORIZONTAL )
- /***********************************************************************
- *
- * @macro: FT_HAS_VERTICAL (face)
- *
- * @description:
- * a macro that returns true whenever a face object contains vertical
- * metrics.
- */
+
+ /*************************************************************************/
+ /* */
+ /* @macro: FT_HAS_VERTICAL (face) */
+ /* */
+ /* @description: */
+ /* A macro that returns true whenever a face object contains vertical */
+ /* metrics. */
+ /* */
#define FT_HAS_VERTICAL( face ) \
( face->face_flags & FT_FACE_FLAG_VERTICAL )
- /***********************************************************************
- *
- * @macro: FT_HAS_KERNING (face)
- *
- * @description:
- * a macro that returns true whenever a face object contains kerning
- * data that can be accessed with @FT_Get_Kerning
- */
+
+ /*************************************************************************/
+ /* */
+ /* @macro: FT_HAS_KERNING (face) */
+ /* */
+ /* @description: */
+ /* A macro that returns true whenever a face object contains kerning */
+ /* data that can be accessed with @FT_Get_Kerning. */
+ /* */
#define FT_HAS_KERNING( face ) \
( face->face_flags & FT_FACE_FLAG_KERNING )
- /***********************************************************************
- *
- * @macro: FT_IS_SCALABLE (face)
- *
- * @description:
- * a macro that returns true whenever a face object contains a scalable
- * font face. I.e., true for TrueType, Type 1, CID and OpenType/CFF
- * font formats.
- */
+
+ /*************************************************************************/
+ /* */
+ /* @macro: FT_IS_SCALABLE (face) */
+ /* */
+ /* @description: */
+ /* A macro that returns true whenever a face object contains a */
+ /* scalable font face (true for TrueType, Type 1, CID, and */
+ /* OpenType/CFF font formats. */
+ /* */
#define FT_IS_SCALABLE( face ) \
( face->face_flags & FT_FACE_FLAG_SCALABLE )
- /***********************************************************************
- *
- * @macro: FT_IS_SFNT (face)
- *
- * @description:
- * a macro that returns true whenever a face object contains a font whose
- * format is based on the SFNT storage scheme. This usually means:
- * TrueType fonts, OpenType fonts, as well as SFNT-based embedded bitmap
- * fonts.
- *
- * When this macro is true, all functions defined in @FT_SFNT_NAMES_H
- * and @FT_TRUETYPE_TABLES_H are available
- */
+ /*************************************************************************/
+ /* */
+ /* @macro: FT_IS_SFNT (face) */
+ /* */
+ /* @description: */
+ /* A macro that returns true whenever a face object contains a font */
+ /* whose format is based on the SFNT storage scheme. This usually */
+ /* means: TrueType fonts, OpenType fonts, as well as SFNT-based */
+ /* embedded bitmap fonts. */
+ /* */
+ /* If this macro is true, all functions defined in @FT_SFNT_NAMES_H */
+ /* and @FT_TRUETYPE_TABLES_H are available. */
+ /* */
#define FT_IS_SFNT( face ) \
( face->face_flags & FT_FACE_FLAG_SFNT )
- /***********************************************************************
- *
- * @macro: FT_IS_FIXED_WIDTH (face)
- *
- * @description:
- * a macro that returns true whenever a face object contains a font
- * face that contains fixed-width (or "monospace", "fixed-pitch", etc..)
- * glyphs.
- */
+
+ /*************************************************************************/
+ /* */
+ /* @macro: FT_IS_FIXED_WIDTH (face) */
+ /* */
+ /* @description: */
+ /* A macro that returns true whenever a face object contains a font */
+ /* face that contains fixed-width (or "monospace", "fixed-pitch", */
+ /* etc.) glyphs. */
+ /* */
#define FT_IS_FIXED_WIDTH( face ) \
( face->face_flags & FT_FACE_FLAG_FIXED_WIDTH )
- /***********************************************************************
- *
- * @macro: FT_IS_FIXED_SIZES (face)
- *
- * @description:
- * a macro that returns true whenever a face object contains some
- * embedded bitmaps. See the 'fixed_sizes' field of the @FT_FaceRec
- * structure.
- */
+ /*************************************************************************/
+ /* */
+ /* @macro: FT_IS_FIXED_SIZES (face) */
+ /* */
+ /* @description: */
+ /* A macro that returns true whenever a face object contains some */
+ /* embedded bitmaps. See the `fixed_sizes' field of the @FT_FaceRec */
+ /* structure. */
+ /* */
#define FT_HAS_FIXED_SIZES( face ) \
( face->face_flags & FT_FACE_FLAG_FIXED_SIZES )
+
/* */
-
+
+
+ /*************************************************************************/
+ /* */
+ /* @macro: FT_HAS_FAST_GLYPHS (face) */
+ /* */
+ /* @description: */
+ /* XXX */
+ /* */
#define FT_HAS_FAST_GLYPHS( face ) \
( face->face_flags & FT_FACE_FLAG_FAST_GLYPHS )
- /***********************************************************************
- *
- * @macro: FT_HAS_GLYPH_NAMES (face)
- *
- * @description:
- * a macro that returns true whenever a face object contains some
- * glyph names that can be accessed through @FT_Get_Glyph_Names
- */
+
+ /*************************************************************************/
+ /* */
+ /* @macro: FT_HAS_GLYPH_NAMES (face) */
+ /* */
+ /* @description: */
+ /* A macro that returns true whenever a face object contains some */
+ /* glyph names that can be accessed through @FT_Get_Glyph_Names. */
+ /* */
#define FT_HAS_GLYPH_NAMES( face ) \
( face->face_flags & FT_FACE_FLAG_GLYPH_NAMES )
- /***********************************************************************
- *
- * @macro: FT_HAS_MULTIPLE_MASTERS (face)
- *
- * @description:
- * a macro that returns true whenever a face object contains some
- * multiple masters. The functions provided by @FT_MULTIPLE_MASTERS_H
- * are then available to choose the exact design you want.
- */
+
+ /*************************************************************************/
+ /* */
+ /* @macro: FT_HAS_MULTIPLE_MASTERS (face) */
+ /* */
+ /* @description: */
+ /* A macro that returns true whenever a face object contains some */
+ /* multiple masters. The functions provided by */
+ /* @FT_MULTIPLE_MASTERS_H are then available to choose the exact */
+ /* design you want. */
+ /* */
#define FT_HAS_MULTIPLE_MASTERS( face ) \
( face->face_flags & FT_FACE_FLAG_MULTIPLE_MASTERS )