changes

source code: Covert TXT to PDF

  - changed the fields  in the FT_Outline structure :  the old "flags"
    array is re-named "tags", while all ancient flags are encoded into
    a single unsigned int named "flags".

  - introduced     new      flags     in     FT_Outline.flags     (see
    ft_outline_.... enums in "ftimage.h").

  - changed outline functions to "FT_Outline_<action>" syntax

  - added a smooth anti-alias renderer to the demonstration programs

  - added Mac graphics driver (thanks Just)

  - 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)

  - 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 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 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:

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);
   }

--- end of CHANGES ---