177 lines
7.4 KiB
Plaintext
177 lines
7.4 KiB
Plaintext
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:
|
|
|
|
|
|
-----------------------------------------------------------------------------------------
|
|
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
|
|
|
|
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/
|
|
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 is 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..
|
|
|
|
|
|
-----------------------------------------------------------------------------------------
|
|
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".
|
|
|
|
|
|
-----------------------------------------------------------------------------------------
|
|
Drivers Interface :
|
|
(To be written)
|
|
|
|
-----------------------------------------------------------------------------------------
|
|
Extensions support :
|
|
(To be defined)
|
|
|