updated the CHANGES file
+ some basic formatting cleaning
This commit is contained in:
David Turner
parent
aa50b821c8
commit
5951ce9fc6
87
CHANGES
87
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);
|
||||
}
|
||||
|
||||
|
|
|
|||
|
|
@ -29,7 +29,6 @@
|
|||
/* The extensions don't need to be integrated at compile time into */
|
||||
/* the engine, only at link time. */
|
||||
|
||||
|
||||
/*****************************************************************
|
||||
*
|
||||
* <FuncType>
|
||||
|
|
|
|||
Loading…
Reference in New Issue