| LATEST CHANGES - |
| |
| - 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). |
| |
| - 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 system: |
| |
| 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); |
| } |
| |