From ab6d10759a8f5f3a4987aeff9e0bd7d79d529c82 Mon Sep 17 00:00:00 2001 From: Werner Lemberg Date: Mon, 2 Apr 2001 21:30:06 +0000 Subject: [PATCH] * 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. --- CHANGES | 1384 ++++++++++++++++++----------------- ChangeLog | 10 +- TODO | 6 +- include/freetype/freetype.h | 188 ++--- 4 files changed, 822 insertions(+), 766 deletions(-) diff --git a/CHANGES b/CHANGES index 674907d95..a3d25c4da 100644 --- a/CHANGES +++ b/CHANGES @@ -4,533 +4,515 @@ LATEST CHANGES BETWEEN 2.0.2 and 2.0.1 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 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 first two items are necessary to correctly a large number of - Type 1 fonts converted to the CFF formats by Adobe Acrobat. + Type 1 fonts converted to the CFF formats by Adobe Acrobat. + - The Type 1 driver was also improved by Tom & others: - - 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) + * 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). + - Various other bugfixes, including the following: - - 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. FT2 now compiles on Epoc again.. + * 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 - #include - #include - #include - - use: - - #include - #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 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: + + #include + #include + #include + #include + + Now you should use: + + #include + #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 DO NOT GUARANTEE THAT THIS WILL STILL BE + TRUE IN THE NEXT ONE (A.K.A. FREETYPE 2.1). + + The file 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. 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 + http://www.freetype.org/ + 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. - - The latter has been updated to support the grouping of sections - in chapters, and better index sort. See: + or - http://www.freetype.org/freetype2/docs/reference/ft2-toc.html + 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. + + The latter has been updated to support the grouping of sections + in chapters and better index sort. See: + + http://www.freetype.org/freetype2/docs/reference/ft2-toc.html III. CHANGES TO THE BUILD PROCESS - - - - 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 - - - - 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.. + - 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. + + 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 + + +====================================================================== -========================================================================= LATEST CHANGES BETWEEN 2.0.1 and 2.0: + 2.0.1 introduces a few changes: - - 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 + - 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". 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. + - Updated the INSTALL file to add IDE compilation. - - fixed some problems with "freetype-config" + - 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. + - Fixed some problems with "freetype-config". 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) ... + gradually changing, but this will be explained in a later release + (probably 2.0.2). - And very special thanks to Tom Kacvinsky and YAMANO-UCHI Hidetoshi for - their contributions! + And very special thanks to Tom Kacvinsky and YAMANO-UCHI Hidetoshi + for their contributions! + + +====================================================================== -========================================================================= CHANGES BETWEEN beta8 and 2.0 - - changed the default installation path for public headers from + - Changed the default installation path for public headers from "include/freetype" to "include/freetype2". - 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.. + 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. - - fixed several small bugs: + - Fixed several small bugs: - - incorrect max advance width for fixed-pitch Type 1 fonts + * 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. - - incorrect glyph names for certain TrueType fonts + - 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). - - the glyph advance was not copied when FT_Glyph_To_Bitmap was called + - Changed "cid" to use "psaux" too. - - the linearHoriAdvance and linerVertAdvance fields were not - correctly returned for glyphs processed by the auto-hinter + - Added the cache sub-system. See as well as + the sources in "src/cache". Note that it compiles but is still + untested for now. - - "type1z" renamed back to "type1"; the old "type1" module has been - removed + - Updated "docs/docmaker.py", a draft API reference is available at + http://www.freetype.org/ft2api.html. - - 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) + - Changed "type1" to use "psaux". - - changed "cid" to use "psaux" too.. + - 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 the cache sub-system. See as well as the - sources in "src/cache". Note that it compiles but is still untested - for now .. + - Fixed an important bug in "FT_Glyph_Get_CBox". - - updated "docs/docmaker.py", a draft API reference is available at - http://www.freetype.org/ft2api.html + - Fixed some compiler warnings that happened since the TrueType + bytecode decoder was deactivated by default. - - changed "type1" to use "psaux" + - Fixed two memory leaks: - - 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 + * 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. - - fixed an important bug in "FT_Glyph_Get_CBox" + - 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. - - fixed some compiler warnings that happened since the TrueType - bytecode decoder was deactivated by default.. - - fixed two memory leaks: - - 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 - - - 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 - - deactivated the trueType bytecode interpreter by default + - Deactivated the TrueType bytecode interpreter by default. - - deactivated the "src/type1" font driver. Now "src/type1z" is - used 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. + - 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. - - added the auto-hinting module !!. Fixing some bugs here and there.. + - Added the auto-hinting module! Fixing some bugs here and there. - - found some bugs in the composite loader (seac) of the Type1-based - font drivers.. + - 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.. + - Renamed the directory "freetype2/config" to "freetype2/builds" and + updated all relevant files. - - found a memory leak in the "type1" driver + - Found a memory leak in the "type1" driver. - - 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.. :-) + - 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.. + - 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'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.. - - I'm still working on the PCF/BDF drivers.. but I'm too lazy - to finish them 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. - CHANGES TO THE HIGH-LEVEL API - 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 ). - - o the outline functions are now in and not - part of anymore - - o 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 now.. - - o anti-aliased rendering is now the default for FT_Render_Glyph + * 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 and not + part of anymore. + * 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 + 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_MONOCHROME flag in FT_Load_Glyph/FT_Load_Char. FT_LOAD_ANTI_ALIAS is still defined, but values to 0. - - o now include , + * now include , solving a few headaches :-) - - o the type FT_GlyphSlotRec has now a "library" field. - - + * The type FT_GlyphSlotRec has now a "library" field. - CHANGES TO THE "ftglyph.h" API - 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. + 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 ?? + - 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 + - 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.. - - + are still there. This functionality will certainly go into a + specific module. - ADDED SUPPORT FOR THE AUTO-HINTER - 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. - - CID fonts are not hinted, as they include no charmap and the auto-hinter - doesn't include "generic" global metrics computations yet.. - - Now, I need to release this thing to the FreeType 2 source.. - - + 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. + CID fonts are not hinted, as they include no charmap and the + auto-hinter doesn't include "generic" global metrics computations + yet. + Now, I need to release this thing to the FreeType 2 source. - CHANGES TO THE RENDERER MODULES - 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.. + 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.. + 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 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 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: + + 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. + + he 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 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 and the FT_GlyphLoader type for + more information. + + * FT_GlyphSlot has 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 + 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 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. - - support for generic glyph image types: + * Support for transforms and direct rendering in FT_Load_Glyph: - The FT_Renderer type is a pointer to a module used to perform various - operations on glyph image. + Most of the functionality found in has been + moved to the core library. Hence, the following: - Each renderer is capable of handling images in a single format - (e.g. ft_glyph_format_outline). Its functions are used to: + - 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. - - transform an glyph image - - render a glyph image into a bitmap - - return the control box (dimensions) of a given glyph image + - 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. - 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 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 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 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. - - - - - - 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 which defines functions to + a new file named 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,131 +521,143 @@ OLD CHANGES FOR BETA 7 - 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: - - simple FreeType types, without the API - - definition of memory-management macros + + - simple FreeType types, without the API + + - definition of memory-management macros - - added the "DSIG" (OpenType Digital Signature) tag to + - added the "DSIG" (OpenType Digital Signature) tag to + - - 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 - - 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.. + 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.. - 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 , as - it was missing from the public header (the implementation was already - in "ftobjs.c"). + - added the declaration of FT_New_Memory_Face in + , as it was missing from the public header + (the implementation was already in "ftobjs.c"). - - the file 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 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 #include 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. #include #include - 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 @@ OLD CHANGES 16 May 2000 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,189 +698,205 @@ OLD CHANGES 16 May 2000 (of course, using -Iconfig/ 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/". + - 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/". - 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_" 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 - 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,28 +907,32 @@ Table Of Contents: 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 @@ -926,12 +940,13 @@ High-Level Interface : 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 @@ Directory Structure: 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,152 +974,165 @@ Directory Structure: 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. + + 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.. ------------------------------------------------------------------------------------------ -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 : +Build system: - - automatic host platform detection (reverting to 'config/ansi' - if it is not detected, with pseudo-standard compilation flags) + 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//detect.mk' for a list of supported compilers - for your platforms. + See the file `config//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//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: - 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 @@ Extensions support : return ext_interface->do_it(ext); } +--- end of CHANGES --- diff --git a/ChangeLog b/ChangeLog index 5a222c746..49af8500b 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,9 @@ +2001-04-02 Werner Lemberg + + * CHANGES: Reformatted, minor fixes. + * TODO: Updated. + * include/freetype/freetype.h: Formatting. + 2001-04-02 Tom Kacvinsky * src/sfnt/ttload.c (TT_Load_Metrics): Fix an improper pointer @@ -11,8 +17,8 @@ 2001-03-24 David Turner - * 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. diff --git a/TODO b/TODO index 0c17acaad..5cf630fc3 100644 --- a/TODO +++ b/TODO @@ -2,11 +2,13 @@ Here is a list of items that need to be addressed in FreeType 2: * 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. diff --git a/include/freetype/freetype.h b/include/freetype/freetype.h index 9ae157de3..7fee26dc0 100644 --- a/include/freetype/freetype.h +++ b/include/freetype/freetype.h @@ -822,123 +822,141 @@ FT_BEGIN_HEADER /* */ #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 )