o provide an interface to retrieve the Postscript names of        the Macintosh, Adobe Standard & Adobe Expert character codes.        (the Macintosh names are used by the SFNT-module postscript         names support routines, while the other two tables are used         by the Type 1 driver(s)).  - introduced the "type1z" alternate Type 1 driver. This is a (still    experimental) driver for the Type 1 format that will ultimately    replace the one in "src/type1". It uses pattern matching to load    data from the font, instead of a finite state analyzer. It works    much better than the "old" driver with "broken" fonts. It is also    much smaller (under 15 Kb).  - the Type 1 drivers (both in "src/type1" and "src/type1z") are    nearly complete. They both provide automatic Unicode charmap    synthesis through the "psnames" module. No re-encoding vector    is needed. (note that they still leak memory due to some code    missing, and I'm getting lazy).    Trivial AFM support has been added to read kerning information    but wasn't exactly tested as it should ;-)  - The TrueType glyph loader has been seriously rewritten (see the    file "src/truetype/ttgload.c". It is now much, much simpler as    well as easier to read, maintain and understand :-) Preliminary    versions introduced a memory leak that has been reported by Jack    Davis, and is now fixed..  - introduced the new "ft_glyph_format_plotter", used to represent    stroked outlines like Windows "Vector" fonts, and certain Type 1    fonts like "Hershey". The corresponding raster will be written    soon.  - FT_New_Memory_Face is gone. Likewise, FT_Open_Face has a new    interface that uses a structure to describe the input stream,    the driver (if required), etc..TODO  - Write FT_Get_Glyph_Bitmap and FT_Load_Glyph_Bitmap  - Add a function like FT_Load_Character( face, char_code, load_flags )    that would really embbed a call to FT_Get_Char_Index then FT_Load_Glyph    to ease developer's work.  - Update the tutorial !!  - consider adding support for Multiple Master fonts in the Type 1    drivers.  - Test the AFM routines of the Type 1 drivers to check that kerning    information is returned correctly.  - write a decent auto-gridding component !! We need this to release    FreeType 2.0 gold !----- less urgent needs : ----------  - add a CFF/Type2 driver  - add a BDF driver  - add a FNT/PCF/HBF driver  - add a Speedo driver from the X11 sources==============================================================================OLDER CHANGES - 27-jan-2000  - 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..  - added an experimental replacement Type 1 driver featuring advanced    (and speedy) pattern matching to retrieve the data from postscript    fonts.  - very minor changes in the implementation of FT_Set_Char_Size and    FT_Set_Pixel_Sizes (they now implement default to ligthen the    font driver's code).=============================================================================OLD MESSAGEThis 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:    I   High-Level Interface (easier !)   II   Directory Structure  III   Glyph Image Formats   IV   Build System    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)    - 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          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-----------------------------------------------------------------------------------------Directory Structure:  Should seem obvious to most of you:     freetype/         config/        -- configuration sub-makefiles            ansi/            unix/       -- platform-specific configuration files            win32/            os2/            msdos/         include/       -- public header files, those to be included directly                           by client apps         src/           -- sources of the library           base/        -- the base layer           sfnt/        -- the sfnt "driver" (see the drivers section below)           truetype/    -- the truetype driver           type1/       -- the type1 driver           shared/      -- some header files shared between drivers         demos/         -- demos/tools         docs/          -- documentation (a bit empty for now)-----------------------------------------------------------------------------------------Glyph Image Formats :  Drivers are now able to register new glyph image formats within the library.  For now, the base layer supports of course bitmaps and vector outlines, but  one could imagine something different like colored bitmaps, bi-color  vectors or wathever else (Metafonts anyone ??).  See the file `include/ftimage.h'. Note also that the type FT_Raster_Map is  gone, and is now replaced by FT_Bitmap, which should encompass all known  bitmap types.  Each new image format must provide at least one "raster", i.e. a module  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 :   - automatic host platform detection (reverting to 'config/ansi'     if it is not detected, with pseudo-standard compilation flags)   - the ability to compile from the Makefiles with very different and     exotic compilers. Note that linking the library can be difficult for     some platforms.     For example, the file `config/win32/lcclib.bat' is invoked by the     build system to create the ".lib" file with LCC-Win32 because its     librarian has too many flaws to be invoked directly from the Makefile.  Here's how it works :  - the first time you type `make', the build system runs a series of    sub-makefiles in order to detect your host platform. It then dumps    what it found, and creates a file called `config.mk' in the current    directory. This is a sub-Makefile used to define many important Make    variables used to build the library.  - the second time, the build system detects the `config.mk' then use it    to build the library. All object files go into 'obj' by default, as    well as the library file, but  this can easily be changed.  Note that you can run "make setup" to force another host platform detection  even if a `config.mk' is present in the current directory. Another solution  is simply to delete the file, then re-run make.  Finally, the default compiler for all platforms is gcc (for now, this will  hopefully changed in the future). You can however specify a different  compiler by specifying it after the 'setup' target as in :      gnumake setup lcc         on Win32 to use the LCC compiler      gnumake setup visualc     on Win32 to use Visual C++  See the file `config/<system>/detect.mk' for a list of supported compilers  for your platforms.  It should be relatively easy to write new detection rules files and  config.mk..  Finally, to build the demo programs, go to `demos' and launch GNU Make,  it will use the `config.mk' in the top directory to build the test  programs..-----------------------------------------------------------------------------------------Portability :  In the previous beta, a single FT_System object was used to encompass  all low-level operations like thread synchronisation, memory management  and i/o access. This has been greatly simplified :    - thread synchronisation has been dropped, for the simple reason that      the library is already re-entrant, and that if you really need two      threads accessing the same FT_Library, you should really synchronize      access to it yourself with a simple mutex.    - memory management is performed through a very simple object called      "FT_Memory", which really is a table containing a table of pointers      to functions like malloc, realloc and free as well as some user data      (closure).    - resources have disappeared (they created more problems than they      solved), and i/o management have been simplified greatly as a      result. Streams are defined through FT_Stream objects, which can      be either memory-based or disk-based.      Note that each face has its own stream, which is closed only when      the face object is destroyed. Hence, a function like TT_Flush_Face      in 1.x cannot be directly supported. However, if you really need      something like this, you can easily tailor your own streams to achieve      the same feature at a lower level (and use FT_Open_Face instead of      FT_New_Face to create the face).  See the file "include/ftsystem.h" for more details, as well as the  implementations found in "config/unix" and "config/ansi".-----------------------------------------------------------------------------------------Font Drivers :  The Font Driver interface has been modified in order to support  extensions & versioning.  The list of the font drivers that are statically linked to the  library at compile time is managed through a new configuration file  called `config/<platform>/ftmodule.h'.  This file is autogenerated when invoking `make modules'. This target  will parse all sub-directories of 'src', looking for a "module.mk"  rules file, used to describe the driver to the build system.  Hence, one should call `make modules' each time a font driver is added  or removed from the `src' directory.  Finally, this version provides a "pseudo-driver" in `src/sfnt'. This  driver doesn't support font files directly, but provides services used  by all TrueType-like font drivers. Hence, its code is shared between  the TrueType & OpenType font formats, and possibly more formats to  come if we're lucky..-----------------------------------------------------------------------------------------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.  Extension ids are now strings, rather than 4-byte tags, as this is  usually more readable..  Each extension has:    - some data, associated to each face object    - an interface (table of function pointers)  An extension that is format-specific should simply register itself  to the correct font driver. Here is some example code:   // Registering an extensions   //   FT_Error  FT_Init_XXXX_Extension( FT_Library  library )   {     FT_DriverInterface*  tt_driver;     driver = FT_Get_Driver( library, "truetype" );     if (!driver) return FT_Err_Unimplemented_Feature;     return FT_Register_Extension( driver, &extension_class );   }   // Implementing the extensions   //   FT_Error  FT_Proceed_Extension_XXX( FT_Face  face )   {     FT_XXX_Extension            ext;     FT_XXX_Extension_Interface  ext_interface;     ext = FT_Get_Extension( face, "extensionid", &ext_interface );     if (!ext) return error;     return ext_interface->do_it(ext);   }