+++ /dev/null
-LATEST CHANGES
-
- - deactivated the trueType bytecode interpreter by default
-
- - deactivated the "src/type1" font driver. Now "src/type1z" is
- used by default..
-
- - updates to the build system. We now compile the library correctly
- under Unix system through "configure" which is automatically called
- on the first "make" invocation.
-
- - added the auto-hinting module !!. Fixing some bugs here and there..
-
- - found some bugs in the composite loader (seac) of the Type1-based
- font drivers..
-
- - renamed the directory "freetype2/config" to "freetype2/builds" and
- updated all relevant files..
-
- - found a memory leak in the "type1" driver
-
- - incorporated Tom's patches to support flex operators correctly
- in OpenType/CFF fonts.. Now all I need is to support pure CFF
- and CEF fonts to be done with this driver.. :-)
-
- - added the Windows FNT/FON driver in "src/winfonts". For now,
- it always "simulates" a Unicode charmap, so it shouldn't be
- considered completed right now..
-
- It's there to be more a proof of concept than anything else
- anyway. The driver is a single C source file, that compiles
- to 3 Kb of code..
-
- I'm still working on the PCF/BDF drivers.. but I'm too lazy
- to finish them now..
-
-
- - CHANGES TO THE HIGH-LEVEL API
-
- o FT_Get_Kerning has a new parameter that allows you to select
- the coordinates of the kerning vector ( font units, scaled,
- scaled + grid-fitted ).
-
- o the outline functions are now in <freetype/ftoutln.h> and not
- part of <freetype/freetype.h> anymore
-
- o <freetype/ftmodule.h> now contains declarations for
- FT_New_Library, FT_Done_Library, FT_Add_Default_Modules
-
- o the so-called convenience functions have moved from "ftoutln.c"
- to "ftglyph.c", and are thus available with this optional component
- of the library. They are declared in <freetype/ftglyph.h> now..
-
- o anti-aliased rendering is now the default for FT_Render_Glyph
- (i.e. corresponds to render_mode == 0 == ft_render_mode_normal).
- To generate a monochrome bitmap, use ft_render_mode_mono, or the
- FT_LOAD_MONOCHROME flag in FT_Load_Glyph/FT_Load_Char.
-
- FT_LOAD_ANTI_ALIAS is still defined, but values to 0.
-
- o <freetype/freetype.h> now include <freetype/config/ftconfig.h>,
- solving a few headaches :-)
-
- o the type FT_GlyphSlotRec has now a "library" field.
-
-
-
- - CHANGES TO THE "ftglyph.h" API
-
- This API has been severely modified in order to make it simpler,
- clearer, and more efficient. It certainly now looks like a real
- "glyph factory" object, and allows client applications to manage
- (i.e. transform, bbox and render) glyph images without ever knowing
- their original format.
-
- - added support for CID-keyed fonts to the CFF driver.
- maybe support for pure CFF + CEF fonts should come in ??
-
-
- - cleaned up source code in order to avoid two functions with the
- same name. Also changed the names of the files in "type1z" from
- "t1XXXX" to "z1XXXX" in order to avoid any conflicts.
-
- "make multi" now works well :-)
-
- Also removed the use of "cidafm" for now, even if the source files
- are still there. This functionality will certainly go into a specific
- module..
-
-
-
- - ADDED SUPPORT FOR THE AUTO-HINTER
-
- It works :-) I have a demo program which simply is a copy of "ftview"
- that does a FT_Add_Module( library, &autohinter_module_class ) after
- library initialisation, and Type 1 & OpenType/CFF fonts are now hinted.
-
- CID fonts are not hinted, as they include no charmap and the auto-hinter
- doesn't include "generic" global metrics computations yet..
-
- Now, I need to release this thing to the FreeType 2 source..
-
-
-
-
-
- - CHANGES TO THE RENDERER MODULES
-
- the monochrome and smooth renderers are now in two distinct directories,
- namely "src/raster1" and "src/smooth". Note that the old "src/renderer"
- is now gone..
-
- I ditched the 5-gray-levels renderers. Basically, it involved a simple
- #define toggle in 'src/raster1/ftraster.c'
-
- FT_Render_Glyph, FT_Outline_Render & FT_Outline_Get_Bitmap now select
- the best renderer available, depending on render mode. If the current
- renderer for a given glyph image format isn't capable of supporting
- the render mode, another one will be found in the library's list.
-
- This means that client applications do not need to switch or set the
- renderers themselves (as in the latest change), they'll get what they
- want automatically... At last..
-
- Changed the demo programs accordingly..
-
-
-
- - MAJOR INTERNAL REDESIGN:
-
- A lot of internal modifications have been performed lately on the
- source in order to provide the following enhancements:
-
- - more generic module support:
-
- The FT_Module type is now defined to represent a handle to a given
- module. The file <freetype/ftmodule.h> contains the FT_Module_Class
- definition, as well as the module-loading public API
-
- The FT_Driver type is still defined, and still represents a pointer
- to a font driver. Note that FT_Add_Driver is replaced by FT_Add_Module,
- FT_Get_Driver by FT_Get_Module, etc..
-
-
- - support for generic glyph image types:
-
- The FT_Renderer type is a pointer to a module used to perform various
- operations on glyph image.
-
- Each renderer is capable of handling images in a single format
- (e.g. ft_glyph_format_outline). Its functions are used to:
-
- - transform an glyph image
- - render a glyph image into a bitmap
- - return the control box (dimensions) of a given glyph image
-
-
- The scan converters "ftraster.c" and "ftgrays.c" have been moved
- to the new directory "src/renderer", and are used to provide two
- default renderer modules.
-
- One corresponds to the "standard" scan-converter, the other to the
- "smooth" one.
-
- The current renderer can be set through the new function
- FT_Set_Renderer.
-
- The old raster-related function FT_Set_Raster, FT_Get_Raster and
- FT_Set_Raster_Mode have now disappeared, in favor of the new:
-
- FT_Get_Renderer
- FT_Set_Renderer
-
- see the file <freetype/ftrender.h> for more details..
-
- These changes were necessary to properly support different scalable
- formats in the future, like bi-color glyphs, etc..
-
-
- - glyph loader object:
-
- A new internal object, called a 'glyph loader' has been introduced
- in the base layer. It is used by all scalable format font drivers
- to load glyphs and composites.
-
- This object has been created to reduce the code size of each driver,
- as each one of them basically re-implemented its functionality.
-
- See <freetype/internal/ftobjs.h> and the FT_GlyphLoader type for
- more information..
-
-
-
- - FT_GlyphSlot had new fields:
-
- In order to support extended features (see below), the FT_GlyphSlot
- structure has a few new fields:
-
- linearHoriAdvance: this field gives the linearly scaled (i.e.
- scaled but unhinted) advance width for the glyph,
- expressed as a 16.16 fixed pixel value. This
- is useful to perform WYSIWYG text.
-
- linearVertAdvance: this field gives the linearly scaled advance
- height for the glyph (relevant in vertical glyph
- layouts only). This is useful to perform
- WYSIWYG text.
-
- Note that the two above field replace the removed "metrics2" field
- in the glyph slot.
-
- advance: this field is a vector that gives the transformed
- advance for the glyph. By default, it corresponds
- to the advance width, unless FT_LOAD_VERTICAL_LAYOUT
- was specified when calling FT_Load_Glyph or FT_Load_Char
-
- bitmap_left: this field gives the distance in integer pixels from
- the current pen position to the left-most pixel of
- a glyph image WHEN IT IS A BITMAP. It is only valid
- when the "format" field is set to
- "ft_glyph_format_bitmap", for example, after calling
- the new function FT_Render_Glyph.
-
- bitmap_top: this field gives the distance in integer pixels from
- the current pen position (located on the baseline) to
- the top-most pixel of the glyph image WHEN IT IS A
- BITMAP. Positive values correspond to upwards Y.
-
- loader: this is a new private field for the glyph slot. Client
- applications should not touch it..
-
-
- - support for transforms and direct rendering in FT_Load_Glyph:
-
- Most of the functionality found in <freetype/ftglyph.h> has been
- moved to the core library. Hence, the following:
-
- - a transform can be specified for a face through FT_Set_Transform.
- this transform is applied by FT_Load_Glyph to scalable glyph images
- (i.e. NOT TO BITMAPS) before the function returns, unless the
- bit flag FT_LOAD_IGNORE_TRANSFORM was set in the load flags..
-
-
- - once a glyph image has been loaded, it can be directly converted to
- a bitmap by using the new FT_Render_Glyph function. Note that this
- function takes the glyph image from the glyph slot, and converts
- it to a bitmap whose properties are returned in "face.glyph.bitmap",
- "face.glyph.bitmap_left" and "face.glyph.bitmap_top". The original
- native image might be lost after the conversion.
-
-
- - when using the new bit flag FT_LOAD_RENDER, the FT_Load_Glyph
- and FT_Load_Char functions will call FT_Render_Glyph automatically
- when needed.
-
-
-
-
- - reformated all modules source code in order to get rid of the basic
- data types redifinitions (i.e. "TT_Int" instead of "FT_Int", "T1_Fixed"
- instead of "FT_Fixed"). Hence the format-specific prefixes like "TT_",
- "T1_", "T2_" and "CID_" are only used for relevant structures..
-
-============================================================================
-OLD CHANGES FOR BETA 7
-
- - bug-fixed the OpenType/CFF parser. It now loads and displays my two
- fonts nicely, but I'm pretty certain that more testing is needed :-)
-
- - fixed the crummy Type 1 hinter, it now handles accented characters
- correctly (well, the accent is not always well placed, but that's
- another problem..)
-
- - added the CID-keyed Type 1 driver in "src/cid". Works pretty well for
- only 13 Kb of code ;-) Doesn't read AFM files though, nor the really
- useful CMAP files..
-
- - fixed two bugs in the smooth renderer (src/base/ftgrays.c). Thanks to
- Boris Letocha for spotting them and providing a fix..
-
- - fixed potential "divide by zero" bugs in ftcalc.c.. my god..
-
- - added source code for the OpenType/CFF driver (still incomplete though..)
-
- - modified the SFNT driver slightly to perform more robust header
- checks in TT_Load_SFNT_Header. This prevents certain font files
- (e.g. some Type 1 Multiple Masters) from being incorrectly "recognized"
- as TrueType font files..
-
- - moved a lot of stuff from the TrueType driver to the SFNT module,
- this allows greater code re-use between font drivers (e.g. TrueType,
- OpenType, Compact-TrueType, etc..)
-
- - added a tiny segment cache to the SFNT Charmap 4 decoder, in order
- to minimally speed it up..
-
- - added support for Multiple Master fonts in "type1z". There is also
- a new file named <freetype/ftmm.h> which defines functions to
- manage them from client applications.
-
- The new file "src/base/ftmm.c" is also optional to the engine..
-
- - various formatting changes (e.g. EXPORT_DEF -> FT_EXPORT_DEF) +
- small bug fixes in FT_Load_Glyph, the "type1" driver, etc..
-
- - a minor fix to the Type 1 driver to let them apply the font matrix
- correctly (used for many oblique fonts..)
-
- - some fixes for 64-bit systems (mainly changing some FT_TRACE calls
- to use %p instead of %lx).. Thanks to Karl Robillard
-
- - fixed some bugs in the sbit loader (src/base/sfnt/ttsbit.c) + added
- a new flag, FT_LOAD_CROP_BITMAP to query that bitmaps be cropped when
- loaded from a file (maybe I should move the bitmap cropper to the
- base layer ??).
-
- - changed the default number of gray levels of the smooth renderer to
- 256 (instead of the previous 128). Of course, the human eye can't
- see any difference ;-)
-
- - removed TT_MAX_SUBGLYPHS, there is no static limit on the number of
- subglyphs in a TrueType font now..
-
-=============================================================================
-OLD CHANGES 16 May 2000
-
- - tagged "BETA-6" in the CVS tree. This one is a serious release candidate
- even though it doesn't incorporate the auto-hinter yet..
-
- - various obsolete files were removed, and copyright header updated
-
- - finally updated the standard raster to fix the monochrome rendering bug
- + re-enable support for 5-gray levels anti-aliasing (suck, suck..)
-
- - created new header files, and modified sources accordingly:
-
- <freetype/fttypes.h> - simple FreeType types, without the API
- <freetype/internal/ftmemory.h> - definition of memory-management macros
-
- - added the "DSIG" (OpenType Digital Signature) tag to <freetype/tttags.h>
-
- - light update/cleaning of the build system + changes to the sources in
- order to get rid of _all_ compiler warnings with three compilers, i.e:
-
- gcc with "-ansi -pedantic -Wall -W", Visual C++ with "/W3 /WX"
- and LCC
-
- IMPORTANT NOTE FOR WIN32-LCC USERS:
- |
- | It seems the C pre-processor that comes with LCC is broken, it
- | doesn't recognize the ANSI standard directives # and ## correctly
- | when one of the argument is a macro. Also, something like:
- |
- | #define F(x) print##x
- |
- | F(("hello"))
- |
- | will get incorrectly translated to:
- |
- | print "hello")
- |
- | by its pre-processor. For this reason, you simply cannot build
- | FreeType 2 in debug mode with this compiler..
-
-
- - yet another massive grunt work. I've changed the definition of the
- EXPORT_DEF, EXPORT_FUNC, BASE_DEF & BASE_FUNC macros. These now take
- an argument, which is the function's return value type.
-
- This is necessary to compile FreeType as a DLL on Windows and OS/2.
- Depending on the compiler used, a compiler-specific keyword like __export
- or __system must be placed before (VisualC++) or after (BorlandC++)
- the type..
-
- Of course, this needed a lot of changes throughout the source code
- to make it compile again... All cleaned up now, apparently..
-
- Note also that there is a new EXPORT_VAR macro defined to allow the
- _declaration_ of an exportable public (constant) variable. This is the
- case of the raster interfaces (see ftraster.h and ftgrays.h), as well
- as each module's interface (see sfdriver.h, psdriver.h, etc..)
-
- - new feature: it is now possible to pass extra parameters to font
- drivers when creating a new face object. For now, this
- capability is unused. It could however prove to be useful
- in a near future..
-
- the FT_Open_Args structure was changes, as well as the internal
- driver interface (the specific "init_face" module function has now
- a different signature).
-
- - updated the tutorial (not finished though).
- - updated the top-level BUILD document
-
- - fixed a potential memory leak that could occur when loading embedded
- bitmaps.
-
- - added the declaration of FT_New_Memory_Face in <freetype/freetype.h>, as
- it was missing from the public header (the implementation was already
- in "ftobjs.c").
-
- - the file <freetype/fterrors.h> has been seriously updated in order to
- allow the automatic generation of error message tables. See the comments
- within it for more information.
-
- - major directory hierarchy re-organisation. This was done for two things:
-
- * first, to ease the "manual" compilation of the library by requiring
- at lot less include paths :-)
-
- * second, to allow external programs to effectively access internal
- data fields. For example, this can be extremely useful if someone
- wants to write a font producer or a font manager on top of FreeType.
-
- Basically, you should now use the 'freetype/' prefix for header inclusion,
- as in:
-
- #include <freetype/freetype.h>
- #include <freetype/ftglyph.h>
-
- Some new include sub-directories are available:
-
- a. the "freetype/config" directory, contains two files used to
- configure the build of the library. Client applications should
- not need to look at these normally, but they can if they want.
-
- #include <freetype/config/ftoption.h>
- #include <freetype/config/ftconfig.h>
-
- b. the "freetype/internal" directory, contains header files that
- describes library internals. These are the header files that were
- previously found in the "src/base" and "src/shared" directories.
-
-
- As usual, the build system and the demos have been updated to reflect
- the change..
-
- Here's a layout of the new directory hierarchy:
-
- TOP
- include/
- freetype/
- freetype.h
- ...
- config/
- ftoption.h
- ftconfig.h
- ftmodule.h
-
- internal/
- ftobjs.h
- ftstream.h
- ftcalc.h
- ...
-
- src/
- base/
- ...
-
- sfnt/
- psnames/
- truetype/
- type1/
- type1z/
-
-
- Compiling a module is now much easier, for example, the following should
- work when in the TOP directory on an ANSI build:
-
- gcc -c -I./include -I./src/base src/base/ftbase.c
- gcc -c -I./include -I./src/sfnt src/sfnt/sfnt.c
- etc..
-
- (of course, using -Iconfig/<system> if you provide system-specific
- configuration files).
-
-
- - updated the structure of FT_Outline_Funcs in order to allow
- direct coordinate scaling within the outline decomposition routine
- (this is important for virtual "on" points with TrueType outlines)
- + updates to the rasters to support this..
-
- - updated the OS/2 table loading code in "src/sfnt/ttload.c" in order
- to support version 2 of the table (see OpenType 1.2 spec)
-
- - created "include/tttables.h" and "include/t1tables.h" to allow
- client applications to access some of the SFNT and T1 tables of a
- face with a procedural interface (see FT_Get_Sfnt_Table())
- + updates to internal source files to reflect the change..
-
- - some cleanups in the source code to get rid of warnings when compiling
- with the "-Wall -W -ansi -pedantic" options in gcc.
-
- - debugged and moved the smooth renderer to "src/base/ftgrays.c" and
- its header to "include/ftgrays.h"
-
- - updated TT_MAX_SUBGLYPHS to 96 as some CJK fonts have composites with
- up to 80 sub-glyphs !! Thanks to Werner
-
-================================================================================
-OLD CHANGES - 14-apr-2000
-
- - fixed a bug in the TrueType glyph loader that prevented the correct
- loading of some CJK glyphs in mingli.ttf
-
- - improved the standard Type 1 hinter in "src/type1"
-
- - fixed two bugs in the experimental Type 1 driver in "src/type1z"
- to handle the new XFree86 4.0 fonts (and a few other ones..)
-
- - the smooth renderer is now complete and supports sub-banding
- to render large glyphs at high speed. However, it is still located
- in "demos/src/ftgrays.c" and should move to the library itself
- in the next beta.. NOTE: The smooth renderer doesn't compile in
- stand-alone mode anymore, but this should be fixed RSN..
-
- - introduced convenience functions to more easily deal with glyph
- images, see "include/ftglyph.h" for more details, as well as the
- new demo program named "demos/src/ftstring.c" that demonstrates
- its use
-
- - implemented FT_LOAD_NO_RECURSE in both the TrueType and Type 1
- drivers (this is required by the auto-hinter to improve its results).
-
- - changed the raster interface, in order to allow client applications
- to provide their own span-drawing callbacks. However, only the
- smooth renderer supports this. See "FT_Raster_Params" in the
- file "include/ftimage.h"
-
- - fixed a small bug in FT_MulFix that caused incorrect transform
- computation !!
-
- - Note: The tutorial is out-of-date, grumpf.. :-(
-
-================================================================================
-OLD CHANGES - 12-mar-2000
-
- - changed the layout of configuration files : now, all ANSI configuration
- files are located in "freetype2/config". System-specific over-rides
- can be placed in "freetype2/config/<system>".
-
- - moved all configuration macros to "config/ftoption.h"
-
- - improvements in the Type 1 driver with AFM support
-
- - 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);
- }
-
git://git.jankratochvil.net / reactos.git / blobdiff