kc3-lang/freetype

diff --git a/CHANGES b/CHANGES
index cc42e48..b25de4c 100644
--- a/CHANGES
+++ b/CHANGES
@@ -1,14 +1,22 @@
 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
+    - 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
@@ -29,6 +37,7 @@ High-Level Interface :
           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
@@ -43,7 +52,7 @@ Directory Structure:
      freetype/
          config/        -- configuration sub-makefiles
             ansi/
-            unix/
+            unix/       -- platform-specific configuration files
             win32/
             os2/
             msdos/
@@ -75,12 +84,12 @@ Glyph Image Formats :
   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 is also possible
+  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 to be able to display these..
+  updated significantly in order to display these..
 
 
 -----------------------------------------------------------------------------------------
@@ -167,10 +176,72 @@ Portability :
 
 
 -----------------------------------------------------------------------------------------
-Drivers Interface :
-  (To be written)
+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 :
-  (To be defined)
+
+  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);
+   }
 
diff --git a/src/base/ftextend.h b/src/base/ftextend.h
index 4433a3b..b62a5cf 100644
--- a/src/base/ftextend.h
+++ b/src/base/ftextend.h
@@ -29,7 +29,6 @@
   /* The extensions don't need to be integrated at compile time into */
   /* the engine, only at link time.                                  */
 
-
  /*****************************************************************
   *
   * <FuncType>