updated the CHANGES file + some basic formatting cleaning
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149
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>