diff options
Diffstat (limited to 'nx-X11/extras/freetype2/docs')
22 files changed, 4858 insertions, 0 deletions
diff --git a/nx-X11/extras/freetype2/docs/CHANGES b/nx-X11/extras/freetype2/docs/CHANGES new file mode 100644 index 000000000..fdb9ce33d --- /dev/null +++ b/nx-X11/extras/freetype2/docs/CHANGES @@ -0,0 +1,2477 @@ + +LATEST CHANGES BETWEEN 2.1.9 and 2.1.8 + + I. IMPORTANT BUG FIXES + + - The function `FT_Get_CharMap_Index' was only declared, without + any real code. For consistency, it has been renamed to + `FT_Get_Charmap_Index'. (This function is needed to implement + cmap caches.) + + - `FT_Outline_Get_BBox' sometimes returned incorrect values for + conic outlines (e.g., for TrueType fonts). + + - Handling of `bhed' table has been fixed. + + - The TrueType driver with enabled byte code interpreter sometimes + returned artifacts due to incorrect rounding. This bug has been + introduced after version 2.1.4. + + - The BDF driver dropped the last glyph in the font. + + - The BDF driver now uses the DEFAULT_CHAR property (if available) + to select a glyph shape for the undefined glyph. + + + II. IMPORTANT CHANGES + + - George Williams contributed code to handle Apple's font + distortion technology found in GX fonts (`avar', `cvar', `fvar', + and `gvar' tables; the Multiple Masters API has been slightly + extended to cope with the new functionality). + + - The `FT_GlyphSlotRec' structure has been extended: The elements + `lsb_delta' and `rsb_delta' give the difference between hinted + and unhinted left and right side bearings if autohinting is + active. Using those values can improve the inter-letter spacing + considerably. See the documentation of `FT_GlyphSlotRec' and + the `ftstring' demo program how to use it. + + + III. MISCELLANEOUS + + - A new documentation file `formats.txt' describes various font + formats supported (and not supported) by FreeType. + + +====================================================================== + +LATEST CHANGES BETWEEN 2.1.8 and 2.1.7 + + I. IMPORTANT BUG FIXES + + - The native TrueType hinter contained some bugs which prevented + some fonts to be rendered correctly, most notably Legendum.otf. + + - The PostScript hinter now produces improved results. + + - The linear advance width and height values were incorrectly + rounded, making them virtually unusable if not loaded with + FT_LOAD_LINEAR_DESIGN. + + - Indexing CID-keyed CFF fonts is now working: The glyph index is + correctly treated as a CID, similar to FreeType's CID driver + module. Note that CID CMap support is still missing. + + - The FT_FACE_FLAGS_GLYPH_NAMES flag is now set correctly for all + font formats. + + - Some subsetted Type 1 fonts weren't parsed correctly. This bug + has been introduced in 2.1.7. In summary, the Type 1 parser has + become more robust. + + - Non-decimal numbers weren't parsed correctly in PS fonts. + + - The WinFNT driver now correctly reports FT_ENCODING_NONE for all + but one encoding. Use the new FT_WinFNT_ID_XXX values together + with FT_Get_WinFNT_Header() to get the WinFNT charset ID. + + - The descender metrics (face->size->metrics.descender) for WinFNT + bitmap fonts had the wrong sign. + + - The (emulated) `seac' support for CFF fonts was broken. + + - The `flex' operator didn't work for CFF fonts. + + - PS glyphs which use the `hintmask' operator haven't been + rendered correctly in some cases. + + - Metrics for BDF and PCF bitmap font formats have been fixed. + + - Autohinting is now disabled for glyphs which are vertically + distorted or mirrored (using a transformation matrix). This + fixes a bug which produced zero-height glyphs. + + - The `freetype-config' script now handles --prefix and + --exec-prefix correctly; it also returns the proper --rpath (or + -R) value if FreeType has been built as a shared library. + + + II. IMPORTANT CHANGES + + - Both PCF and BDF drivers now handle the SETWIDTH_NAME and + ADD_STYLE_NAME properties. Values are appended to + face->style_name; example: `Bold SemiCondensed'. + + - The PCF driver now handles bitmap fonts compressed with the LZW + algorithm (extension .pcf.Z, compressed with `compress'). + + - A new API function `FT_Get_CMap_Language_ID' (declared in + `tttables.h') is available to get the language ID of a + TrueType/SFNT cmap. + + - The hexadecimal format of data after the `StartData' command in + CID-keyed Type 1 fonts is now supported. While this can't occur + in file-based fonts, it can happen in document-embedded + resources of PostScript documents. + + - Embedded bitmaps in SFNT-based CFF fonts are now supported. + + - A simple API is now available to control FreeType's tracing + mechanism if compiled with FT_DEBUG_LEVEL_TRACE. See the file + `ftdebug.h' for more details. + + - YAMATO Masatake contributed improved handling of MacOS resource + forks on non-MacOS platforms (for example, Linux can mount MacOS + file systems). + + - Support for MacOS has been improved; there is now a new function + `FT_New_Face_From_FSSpec' similar to `FT_New_Face' except that + it accepts an FSSpec instead of a path. + + - The cache sub-system has been rewritten. + + - There is now support for deinstallation of faces. + + - A new API function `FTC_Manager_RemoveFaceID' has been added + to delete all `idle' nodes that correspond to a given + FTC_FaceID. All `locked' nodes (i.e., those with a reference + count > 0), will be modified to prevent them from appearing in + further lookups (they will be cleaned normally when their + reference count reaches 0). + + - There is now support for point scaling (i.e., providing + character sizes in points + dpis, instead of pixels). + + - Three abstract cache classes are now available: + + FTC_GCache: Used to store one glyph item per cache node, + with the ability to group common attributes into + `families'. This replaces the old + FTC_GlyphCache class. + + FTC_ICache: Used to store one FT_Glyph per cache node. This + extends FTC_GCache. Family definition, family + comparison, and glyph loading are however left + to sub-classes. + + FTC_SCache: Used to store up to 16 small bitmaps per cache + node. This extends FTC_GCache. Family + definition, family comparison and glyph loading + are however left to sub-classes. + + - The file `src/cache/ftcbasic.c' implements: + + FTC_ImageCache: Extends FTC_ICache; implements family + definitions and glyph loading similar to the + old API. + + FTC_SBitCache: Extends FTC_SCache, implements family + definitions and glyph loading similar to the + old API + + Client applications should be able to extend FTC_GCache, + FTC_ICache, or FTC_SCache much more easily (i.e., less code to + write, and less callbacks). For example, one could envision + caches that are capable of storing transformed (obliqued), + stroked, emboldened, or colored glyph images. Use + `ftcbasic.c' as an example. + + - All public APIs are now in `include/freetype/ftcache.h', (to + be accessed as `FT_CACHE_H'). The contents of + `include/freetype/cache/' is only needed by applications that + wish to implement their own caches. + + - There were some major performance improvements through the use + of various programming tricks. Cache hits are up to 70% + faster than in the old code. + + - The FTC_CMapCache has been simplied. Charmaps can only be + accessed by index right now. There is also a new API named + `FT_Charmap_GetIndex' for this purpose. + + - The demo programs have been updated to the new code. The + previous versions will not work with the current one. + + - Using an invalid face index in FT_Open_Face and friends now + causes an error even if the font contains a single face only. + + + III. MISCELLANEOUS + + - Wolfgang Domröse contributed support files for building FreeType + on the Atari using the PureC compiler. Note that the Atari is a + 16bit platform. + + - Vitaliy Pasternak contributed project files for VS.NET 2003. + + +====================================================================== + +LATEST CHANGES BETWEEN 2.1.7 and 2.1.6 + + I. IMPORTANT BUG FIXES + + - Updated to newest libtool version, fixing build problems on + various platforms. + + - On Unix platforms, `make install' didn't copy the correct + `ftconfig.h' file. + + Note that version 2.1.7 contains the same library C source code as + version 2.1.6. + + +====================================================================== + +LATEST CHANGES BETWEEN 2.1.6 and 2.1.5 + + I. IMPORTANT BUG FIXES + + - The PFR font driver didn't load kerning tables correctly, and + the functions in FT_PFR_H didn't work at all. + + - Type 1 font files in binary format (PFB) with an end-of-file + indicator weren't accepted by the FreeType engine. + + - Fonts which contain /PaintType and /StrokeWidth no longer cause + a segfault. This bug has been introduced in version 2.1.5. + + - Fonts loaded with FT_LOAD_RENDER no longer cause strange + results. This bug has been introduced in version 2.1.5. + + - Some Windows (bitmap) FNT/FON files couldn't be handled + correctly. + + + II. IMPORTANT CHANGES + + - The internal module API has been heavily changed in favor of + massive simplifications within the font engine. This also means + that authors of third-party modules must adapt their code to the + new scheme. + + NOTE: THE NEW SCHEME IS NOT COMPLETED YET. PLEASE WAIT UNTIL A + FINAL ANNOUNCEMENT! + + - The PostScript parser has been enhanced to handle comments and + strings correctly. Additionally, more syntax forms are + recognized. + + - Added the optional unpatented hinting system for TrueType. It + allows typefaces which need hinting to produce correct glyph + forms (e.g., Chinese typefaces from Dynalab) to work acceptably + without infringing Apple patents. This system is compiled only + if TT_CONFIG_OPTION_COMPILE_UNPATENTED_HINTING is defined in + ftoption.h (activated by default). + + + III. MISCELLANEOUS + + - There is now a guard in the public header files to protect + against inclusion of freetype.h from FreeType 1. + + - Direct inclusion of freetype.h and other public header files no + longer works. You have to use the documented scheme + + #include <ft2build.h> + #include FT_FREETYPE_H + + to load freetype.h with a symbolic name. This protects against + renaming of public header files (which shouldn't happen but + actually has, avoiding two public header files with the same + name). + + +====================================================================== + +LATEST CHANGES BETWEEN 2.1.5 and 2.1.4 + + I. IMPORTANT BUG FIXES + + - Parsing the /CIDFontName field now removes the leading slash to + be in sync with other font drivers. + + - gzip support was buggy. Some fonts could not be read. + + - Fonts which have nested subglyphs more than one level deep no + longer cause a segfault. + + - Creation of synthetic cmaps for fonts in CFF format was broken + partially. + + - Numeric font dictionary entries for synthetic fonts are no + longer overwritten. + + - The font matrix wasn't applied to the advance width for Type1, + CID, and CFF fonts. This caused problems when loading certain + synthetic Type 1 fonts like `Helvetica Narrow'. + + - The test for the charset registry in BDF and PCF fonts is now + case-insensitive. + + - FT_Vector_Rotate sometimes returned strange values due to + rounding errors. + + - The PCF driver now returns the correct number of glyphs + (including an artificial `notdef' glyph at index 0). + + - FreeType now supports buggy CMaps which are contained in many + CJK fonts from Dynalab. + + - Opening an invalid font on a Mac caused a segfault due to + double-freeing memory. + + - BDF fonts with more than 32768 glyphs weren't supported + properly. + + + II. IMPORTANT CHANGES + + - Accessing bitmap font formats has been synchronized. To do that + the FT_Bitmap_Size structure has been extended to contain new + fields `size', `x_ppem', and `y_ppem'. + + - The FNT driver now returns multiple faces, not multiple strikes. + + - The `psnames' module has been updated to the Adobe Glyph List + version 2.0. + + - The `psnames' module now understands `uXXXX[X[X]]' glyph names. + + - The algorithm for guessing the font style has been improved. + + - For fonts in SFNT format, root->height is no longer increased if + the line gap is zero. There exist fonts (containing e.g. form + drawing characters) which intentionally have a zero line gap + value. + + - ft_glyph_bbox_xxx flags are now deprecated in favour of + FT_GLYPH_BBOX_XXX. + + - ft_module_xxx flags are now deprecated in favour of + FT_MODULE_XXX. + + - FT_ENCODING_MS_{SJIS,GB2312,BIG5,WANSUNG,JOHAB} are now + deprecated in favour of + FT_ENCODING_{SJIS,GB2312,GIB5,WANSONG,JOHAB} -- those encodings + are not specific to Microsoft. + + + III. MISCELLANEOUS + + - The autohinter has been further improved; for example, `m' + glyphs now retain its vertical symmetry. + + - Partial support of Mac fonts on non-Mac platforms. + + - `make refdoc' (after first `make') builds the HTML + documentation. You need Python for this. + + - The make build system should now work more reliably on DOS-like + platforms. + + - Support for EMX gcc and Watson C/C++ compilers on MS-DOS has + been added. + + - Better VMS build support. + + - Support for the pkg-config package by providing a `freetype.pc' + file. + + - New configure option --with-old-mac-fonts for Darwin. + + - Some source files have been renamed (mainly to fit into the 8.3 + naming scheme). + + +====================================================================== + +LATEST CHANGES BETWEEN 2.1.4 and 2.1.3 + + I. IMPORTANT BUG FIXES + + - Updated to newest libtool version, fixing build problems on + various platforms. + + - A fix in the Gzip stream reader: It couldn't read certain .gz + files properly due to a small typo. In certain cases, FreeType + could also loop endlessly when trying to load tiny gzipped + files. + + - The configure script now tries to use the system-wide zlib when + it finds one (instead of the copy found in src/gzip). And + "freetype-config" has been updated to return relevant flags in + this case when invoked with "--libs" (e.g. "-lzlib"). + + - Certain fonts couldn't be loaded by 2.1.3 because they lacked a + Unicode charmap (e.g. SYMBOL.TTF). FreeType erroneously + rejected them. + + - The CFF loader was modified to accept fonts which only contain a + subset of their reference charset. This prevented the correct + use of PDF-embedded fonts. + + - The logic to detect Unicode charmaps has been modified. This is + required to support fonts which include both 16-bit and 32-bit + charmaps (like very recent asian ones) using the new 10 and 12 + SFNT formats. + + - The TrueType loader now limits the depth of composite glyphs. + This is necessary to prevent broken fonts to break the engine by + blowing the stack with recursive glyph definitions. + + - The CMap cache is now capable of managing UCS-4 character codes + that are mapped through extended charmaps in recent + TrueType/OpenType fonts. + + - The cache sub-system now properly manages out-of-memory + conditions instead of blindly reporting them to the caller. + This means that it will try to empty the cache before restarting + its allocations to see if that can help. + + - The PFR driver didn't return the list of available embedded + bitmaps properly. + + - There was a nasty memory leak when using embedded bitmaps in + certain font formats. + + + II. IMPORTANT CHANGES + + - David Chester contributed some enhancements to the auto-hinter + that significantly increase the quality of its output. The + Postscript hinter was also improved in several ways. + + - The FT_RENDER_MODE_LIGHT render mode was implemented. + + - A new API function called `FT_Get_BDF_Property' has been added + to FT_BDF_H to retrieve BDF properties from BDF _and_ PCF font + files. THIS IS STILL EXPERIMENTAL, since it hasn't been + properly tested yet. + + - A Windows FNT specific API has been added, mostly to access font + headers. This is used by Wine. + + - TrueType tables without an "hmtx" table are now tolerated when + an incremental interface is used. This happens for certain + Type42 fonts passed from Ghostscript to FreeType. + + - The PFR font driver is now capable of returning the font family + and style names when they are available (instead of the sole + "FontID"). This is performed by parsing an *undocumented* + portion of the font file! + + + III. MISCELLANEOUS + + - The path stroker in FT_STROKER_H has entered beta stage. It now + works very well, but its interface might change a bit in the + future. More on this in later releases. + + - The documentation for FT_Size_Metrics didn't appear properly in + the API reference. + + - The file docs/VERSION.DLL has been updated to explain versioning + with FreeType (i.e., comparing release/libtool/so numbers, and + how to use them in autoconf scripts). + + - The installation documentation has been seriously revamped. + Everything is now in the "docs" directory. + + +====================================================================== + +LATEST CHANGES BETWEEN 2.1.3 and 2.1.2 + + I. IMPORTANT BUG FIXES + + - FT_Vector_Transform had been incorrectly modified in 2.1.2, + resulting in incorrect transformations being applied (for + example, rotations were processed in opposite angles). + + - The format 8 and 12 TrueType charmap enumeration routines have + been fixed (FT_Get_Next_Char returned invalid values). + + - The PFR font driver returned incorrect advance widths if the + outline and metrics resolution defined in the font file were + different. + + - FT_Glyph_To_Bitmap now returns successfully when called with an + FT_BitmapGlyph argument (it previously returned an error). + + - A bug in the Type 1 loader that prevented valid font bounding + boxes to be loaded from multiple master fonts. + + - The SFNT validation code has been rewritten. FreeType can now + load "broken" fonts that were usable on Windows, but not with + previous versions of the library. + + - The computation of bearings in the BDF driver has been fixed. + + - The Postscript hinter crashed when trying to hint certain glyphs + (more precisely, when trying to apply hints to an empty glyph + outline). + + - The TrueType glyph loader now supports composites in "Apple + format" (they differ slightly from Microsoft/OpenType ones in + the way transformation offsets are computed). + + - FreeType was very slow at opening certain asian CID/CFF fonts, + due to fixed increment in dynamic array re-allocations. This + has been changed to exponential behaviour to get acceptable + performance. + + + + II. IMPORTANT CHANGES + + - The PCF driver now supports gzip-compressed font files natively. + This means that you will be able to use all these bitmap fonts + that come with XFree86 with FreeType (and libXft/libXft2, by + extension). + + - The automatic and postscript hinters have both been updated. + This results in a relatively important increase of rendering + quality since many nasty defaults have been supressed. Please + visit the web page: + + http://www.freetype.org/hinting/smooth-hinting.html + + for additional details on this topic. + + - The "load_flags" parameter of FT_Load_Glyph is now an FT_Int32 + (instead of just being an FT_Int). This breaks source and + binary compatibility for 16bit systems only, while retaining + both of them for 32 and 64 bit ones. + + Some new flags have been added consequently: + + FT_LOAD_NO_AUTOHINT :: Disable the use of the auto-hinter + (but not native format hinters). + + FT_LOAD_TARGET_NORMAL :: Hint and render for normal + anti-aliased displays. + + FT_LOAD_TARGET_MONO :: Hint and render for 1-bit displays. + + FT_LOAD_TARGET_LCD :: Hint and render for horizontal RGB or + BGR sub-pixel displays (like LCD + screens). THIS IS STILL + EXPERIMENTAL! + + FT_LOAD_TARGET_LCD_V :: Same as FT_LOAD_TARGET_LCD, for + vertical sub-pixel displays (like + rotated LCD screens). THIS IS STILL + EXPERIMENTAL! + + FT_LOAD_MONOCHROME is still supported, but only affects + rendering, not the hinting. + + Note that the `ftview' demo program available in the `ft2demos' + package has been updated to support LCD-optimized display on + non-paletted displays (under Win32 and X11). + + - The PFR driver now supports embedded bitmaps (all formats + supported), and returns correct kerning metrics for all glyphs. + + - The TrueType charmap loader now supports certain `broken' fonts + that load under Windows without problems. + + - The cache API has been slightly modified (it's still a beta!): + + - The type FTC_ImageDesc has been removed; it is now replaced + by FTC_ImageTypeRec. Note that one of its fields is a + `load_flag' parameter for FT_Load_Glyph. + + - The field "num_grays" of FT_SBitRec has been changed to + "max_grays" in order to fit within a single byte. Its + maximum value is thus 255 (instead of 256 as previously). + + + III. MISCELLANEOUS + + - Added support for the DESTDIR variable during "make install". + This simplifies packaging of FreeType. + + - Included modified copies of the ZLib sources in `src/gzip' in + order to support gzip-compressed PCF fonts. We do not use the + system-provided zlib for now, though this is a probable + enhancement for future releases. + + - The DocMaker tool used to generate the on-line API reference has + been completely rewritten. It is now located in + "src/tools/docmaker/docmaker.py". Features: + + - better cross-referenced output + - more polished output + - uses Python regular expressions (though it didn't speed the + program) + - much more modular structure, which allows for different + "backends" in order to generate HTML, XML, or whatever + format. + + One can regenerate the API reference by calling: + + python src/tools/docmaker/docmaker.py \ + --prefix=ft2 \ + --title=FreeType-2.1.3 \ + --output=<outputdirectory> + include/freetype/*.h \ + include/freetype/config/*.h \ + include/freetype/cache/*.h + + - A new, experimental, support for incremental font loading (i.e., + loading of fonts where the glyphs are not in the font file + itself, but provided by an external component, like a Postscript + interpreter) has been added by Graham Asher. This is still work + in progress, however. + + - A new, EXPERIMENTAL, path stroker has been added. It doesn't + suffer from severe rounding errors and treat bezier arcs + directly. Still work in progress (i.e. not part of the official + API). See the file <freetype/ftstroker.h> for some of the + details. + + - The massive re-formatting of sources and internal re-design is + still under-way. Many internal functions, constants, and types + have been renamed. + + +====================================================================== + +LATEST CHANGES BETWEEN 2.1.2 and 2.1.1 + + I. IMPORTANT BUG FIXES + + - Many font drivers didn't select a Unicode charmap by default + when a new face was opened (with the FT_CONFIG_OPTION_USE_CMAPS + options enabled), causing many applications to not be able to + display text correctly with the 2.1.x releases. + + - The PFR driver had a bug in its composite loading code that + produces incorrectly placed accents with many fonts. + + - The Type42 driver crashed sometimes due to a nasty bug. + + - The Type 1 custom encoding charmap didn't handle the case where + the first glyph index wasn't 0. + + - A serious typo in the TrueType composite loader produced + incorrectly placed glyphs in fonts like "Wingdings" and a few + others. + + + II. MISCELLANEOUS + + - The Win32 Visual C++ project file has been updated to include + the PFR driver as well. + + - "freetype.m4" is now installed by default by "make install" on + Unix systems. + + - The function FT_Get_PS_Font_Info now works with CID and Type42 + fonts as well. + + +====================================================================== + +LATEST CHANGES BETWEEN 2.1.1 and 2.1.0 + + I. IMPORTANT BUG FIXES + + - The `version_info' returned by `freetype-config' in 2.1.0 + returned an invalid value. It now returns 9:1:3 (2.0.9 returned + 9:0:3). + + - Version 2.1.0 couldn't be linked against applications on Win32 + and Amiga systems due to a new debug function that wasn't + properly propagated to the system-specific directory in + `builds'. + + - Various MacOS and Mac OS X specific fixes. + + - Fixed a bug in the TrueType charmap validation routines that + made version 2.1.0 too restrictive -- many popular fonts have + been rejected. + + - There was still a very small difference between the monochrome + glyph bitmaps produced by FreeType 1.x and FreeType 2.x with the + bytecode interpreter enabled. This was caused by an invalid + flag setting in the TrueType glyph loader, making the rasterizer + change its drop-out control mode. Now theresults should + _really_ be completely identical. + + - The TrueType name table loader has been improved to support many + popular though buggy Asian fonts. It now ignores empty name + entries, invalid pointer offsets and a few other incorrect + subtleties. Moreover, name strings are now loaded on demand, + which reduces the memory load of many faces (e.g. the ARIAL.TTF + font file contains a 10kByte name table with 70 names). + + - Fixed a bug in the Postscript hinter that prevented family blues + substitution to happen correctly. + + + II. NEW FEATURES + + - Three new font drivers in this release: + + * A BDF font driver, contributed by Franco Zappa Nardelli, + heavily modified by Werner Lemberg. It also supports + anti-aliased bitmaps (using a slightly extended BDF format). + + * A Type42 font driver, contributed by Roberto Alameda. It is + still experimental but seems to work relatively well. + + * A PFR font driver, contributed by David Turner himself. It + doesn't support PFR hinting -- note that BitStream has at + least two patents on this format! + + + III. MISCELLANEOUS + + - The cache sub-system has been optimized in important ways. + Cache hits are now significantly faster. For example, using the + CMap cache is about twice faster than calling FT_Get_Char_Index + on most platforms. Similarly, using an SBit cache is about five + times faster than loading the bitmaps from a bitmap file, and + 300 to 500 times faster than generating them from a scalable + format. + + Note that you should recompile your sources if you designed a + custom cache class for the FT2 Cache subsystem, since the + changes performed are source, but not binary, compatible. + + +====================================================================== + +LATEST CHANGES BETWEEN 2.1.0 and 2.0.9 + + I. IMPORTANT BUG FIXES + + - The TrueType bytecode interpreter has been fixed to produce + _exactly_ the same output as FreeType 1.x. Previous differences + were due to slightly distinct fixed-point computation routines + used to perform dot products and vector length measurements. + + It seems that native TrueType hinting is _extremely_ sensitive + to rounding errors. The required vector computation routines + have been optimized and placed within the "ttinterp.c" file. + + - Fixed the parsing of accelerator tables in the PCF font driver. + + - Fixed the Type1 glyph loader routine used to compute the font's + maximum advance width. + + + II. NEW FEATURES + + - The `configure' script used on Unix systems has been modified to + check that GNU Make is being used to build the library. + Otherwise, it will display a message proposing to use the + GNUMAKE environment variable to name it. + + The Unix-specific file README.UNX has been modified accordingly. + + + III. MISCELLANEOUS + + - The FreeType License in `docs/FTL.txt' has been updated to + include a proposed preferred disclaimer. If you are using + FreeType in your products, you are encouraged (but not mandated) + to use the following text in your documentation: + + """ + Portions of this software are copyright Š 1996-2002 The + FreeType Project (www.freetype.org). All rights reserved. + """ + + - The default size of the render pool has been reduced to 16kByte. + This shouldn't result in any noticeable performance penalty, + unless you are using the engine as-is to render very large and + complex glyphs. + + - The FreeType 2 redesign has begun. More information can be + found at this URL: + + http://www.freetype.org/freetype2/redesign.html + + The following internal changes have been performed within the + sources of this release: + + - Many internal types have been renamed to increase + consistency. The following should be true, except for + public types: + + * All structure types have a name ending in "Rec" (short + for `record'). + + * A pointer-to-structure type has the same name as the + structure, _without_ the "Rec" suffix. + + Example: + + typedef struct FooRec_ + { + ... + + } FooRec, *Foo; + + - Many internal macros have been renamed to increase + consistency. The following should be true: + + * All macros have a name beginning with "FT_". This + required a few changes like + + ALLOC => FT_ALLOC + FREE => FT_FREE + REALLOC => FT_REALLOC + + * All macros are completely UPPERCASE. This required a + few changes like: + + READ_Short => FT_READ_SHORT + NEXT_Short => FT_NEXT_SHORT + GET_ULongLE => FT_GET_ULONG_LE + MEM_Set => FT_MEM_SET + MEM_Copy => FT_MEM_COPY + etc. + + * Whenever possible, all macro names follow the + FT_<OBJECT>_<METHOD> pattern. For example + + ACCESS_Frame => FT_FRAME_ENTER + FORGET_Frame => FT_FRAME_EXIT + EXTRACT_Frame => FT_FRAME_EXTRACT + RELEASE_Frame => FT_FRAME_RELEASE + + FILE_Pos => FT_STREAM_POS + FILE_Seek => FT_STREAM_SEEK + FILE_Read => FT_STREAM_READ + FILE_ReadAt => FT_STREAM_READ_AT + READ_Fields => FT_STREAM_READ_FIELDS + + - Many internal functions have been renamed to follow the + FT_<Object>_<Method> pattern. For example: + + FT_Seek_Stream => FT_Stream_Seek + FT_Read_Stream_At => FT_Stream_ReadAt + FT_Done_Stream => FT_Stream_Close + FT_New_Stream => FT_Stream_Open + FT_New_Memory_Stream => FT_Stream_OpenMemory + FT_Extract_Frame => FT_Stream_ExtractFrame + + Note that method names do not contain "_". + + - The FT_ALLOC_ARRAY and FT_REALLOC_ARRAY have been replaced + with FT_NEW_ARRAY and FT_RENEW_ARRAY which do not take a + type as the fourth argument. Instead, the array element + type size is computed automatically from the type of the + target pointer used. + + - A new object class, FT_CMap, has been introduced. These + internal objects are used to model character maps. This + eases the support of additional charmap types within the + engine. + + - A new configuration file named "ftstdlib.h" has been added + to `include/freetype/config'. It is used to define aliases + for _every_ routine of the ISO C library that the font + engine uses. Each aliases has a "ft_" prefix + (e.g. "ft_strlen" is an alias for "strlen"). + + This is used to ease the porting of FreeType 2 to exotic + runtime environments where the ISO C Library isn't available + (e.g. XFree86 extension modules). + + More details are available in the "ChangeLog" file. + + +====================================================================== + +LATEST CHANGES BETWEEN 2.0.9 and 2.0.8 + + I. IMPORTANT BUG FIXES + + - Certain fonts like "foxjump.ttf" contain broken name tables with + invalid entries and wild offsets. This caused FreeType to crash + when trying to load them. + + The SFNT `name' table loader has been fixed to be able to + support these strange fonts. + + Moreover, the code in charge of processing this table has been + changed to always favour Windows-formatted entries over other + ones. Hence, a font that works on Windows but not on the Mac + will load cleanly in FreeType and report accurate values for + Family & PostScript names. + + - The CID font driver has been fixed. It unfortunately returned a + Postscript Font name with a leading slash, as in + "/MunhwaGothic-Regular". + + - FreeType 2 should now compile fine on AIX 4.3.3 as a shared + library. + + - A bug in the Postscript hinter has been found and fixed, + removing un-even stem widths at small pixel sizes (like 14-17). + + This improves the quality of a certain number of Postscript + fonts. + + + II. NEW FEATURES + + - A new function named `FT_Library_Version' has been added to + return the current library's major, minor, and patch version + numbers. This is important since the macros FREETYPE_MAJOR, + FREETYPE_MINOR, and FREETYPE_PATCH cannot be used when the + library is dynamically linked by a program. + + - Two new APIs have been added: `FT_Get_First_Char' and + `FT_Get_Next_Char'. + + Together, these can be used to iterate efficiently over the + currently selected charmap of a given face. Read the API + reference for more details. + + + III. MISCELLANEOUS + + - The FreeType sources are under heavy internal re-factoring. As + a consequence, we have created a branch named "STABLE" on the + CVS to hold all future releases/fixes in the 2.0.x family. + + The HEAD branch now contains the re-factored sources and + shouldn't be used for testing or packaging new releases. In + case you would like to access the 2.0.9 sources from our CVS + repository, use the tag `VER-2-0-9'. + + +====================================================================== + +LATEST CHANGES BETWEEN 2.0.8 and 2.0.7 + + I. IMPORTANT BUG FIXES + + - There was a small but nasty bug in "freetype-config.in" which + caused the "freetype-config" script to fail on Unix. + + This didn't prevent the installation of the library or even its + execution, but caused problems when trying to compile many Unix + packages that depend on it. + + - Some TrueType or OpenType fonts embedded in PDF documents do not + have a 'cmap', 'post' and 'name' as is required by the + specification. FreeType no longer refuses to load such fonts. + + - Various fixes to the PCF font driver. + + +====================================================================== + +LATEST CHANGES BETWEEN 2.0.7 and 2.0.6 + + I. IMPORTANT BUG FIXES + + - Fixed two bugs in the Type 1 font driver. The first one + resulted in a memory leak in subtle cases. The other one caused + FreeType to crash when trying to load ".gsf" files (Ghostscript + so-called Postscript fonts). + + (This made _many_ KDE applications crash on certain systems. + FreeType _is_ becoming a critical system component on Linux :-) + + - Fixed a memory leak in the CFF font driver. + + - Fixed a memory leak in the PCF font driver. + + - Fixed the Visual C++ project file + "builds/win32/visualc/freetype.dsp" since it didn't include the + Postscript hinter component, causing errors at build time. + + - Fixed a small rendering bug in the anti-aliased renderer that + only occurred when trying to draw thin (less than 1 pixel) + strokes. + + - Fixed "builds/unix/freetype2.a4" which is used to generate a + valid "freetype2.m4" for use with autoconf. + + - Fixed the OpenVMS Makefiles. + + + II. MISCELLANEOUS + + - Added "configure" and "install" scripts to the top-level + directory. A GNU-style installation is thus now easily possible + with + + ./configure <options> + make + make install + + +====================================================================== + +LATEST CHANGES BETWEEN 2.0.6 and 2.0.5 + + I. IMPORTANT BUG FIXES + + - It wasn't possible to load embedded bitmaps when the auto-hinter + was used. This is now fixed. + + - The TrueType font driver didn't load some composites properly + (the sub-glyphs were slightly shifted, and this was only + noticeable when using monochrome rendering). + + - Various fixes to the auto-hinter. They merely improve the + output of sans-serif fonts. Note that there are still problems + with serifed fonts and composites (accented characters). + + - All scalable font drivers erroneously returned un-fitted glyph + advances when hinting was requested. This created problems for + a number of layout applications. This is a very old bug that + got undetected mainly because most test/demo program perform + rounding explicitly or implicitly (through the cache). + + - FT_Glyph_To_Bitmap() did erroneously modify the source glyph in + certain cases. + + - "glnames.py" still contained a bug that made FreeType return + invalid names for certain glyphs. + + - The library crashed when loading certain Type 1 fonts like + "sadn.pfb" ("Stalingrad Normal"), which appear to contain + pathetic font info dictionaries. + + - The TrueType glyph loader is now much more paranoid and checks + everything when loading a given glyph image. This was necessary + to avoid problems (crashes and/or memory overwrites) with broken + fonts that came from a really buggy automatic font converter. + + + II. IMPORTANT UPDATES AND NEW FEATURES + + - Important updates to the Mac-specific parts of the library. + + - The caching sub-system has been completely re-designed, and its + API has evolved (the old one is still supported for backwards + compatibility). + + The documentation for it is not yet completed, sorry. For now, + you are encouraged to continue using the old API. However, the + ftview demo program in the ft2demos package has already been + updated to use the new caching functions. + + - A new charmap cache is provided too. See FTC_CMapCache(). This + is useful to perform character code -> glyph index translations + quickly, without the need for an opened FT_Face. + + - A NEW POSTSCRIPT HINTER module has been added to support native + hints in the following formats: PostScript Type 1, PostScript + CID, and CFF/CEF. + + Please test! Note that the auto-hinter produces better results + for a number of badly-hinted fonts (mostly auto-generated ones) + though. + + - A memory debugger is now part of the standard FreeType sources. + To enable it, define FT_DEBUG_MEMORY in + <freetype/config/ftoption.h>, and recompile the library. + + Additionally, define the _environment_ variable FT_DEBUG_MEMORY + and run any program using FreeType. When the library is exited, + a summary of memory footprints and possible leaks will be + displayed. + + This works transparently with _any_ program that uses FreeType. + However, you will need a lot of memory to use this (allocated + blocks are never released to the heap to detect double deletes + easily). + + + III. MISCELLANEOUS + + - We are aware of subtle differences between the output of + FreeType versions 1 and 2 when it comes to monochrome + TrueType-hinted glyphs. These are most probably due to small + differences in the monochrome rasterizers and will be worked out + in an upcoming release. + + - We have decided to fork the sources in a "stable" branch, and an + "unstable" one, since FreeType is becoming a critical component + of many Unix systems. + + The next bug-fix releases of the library will be named 2.0.7, + 2.0.8, etc., while the "2.1" branch will contain a version of + the sources where we will start major reworking of the library's + internals, in order to produce FreeType 2.2.0 (or even 3.0) in a + more distant future. + + We also hope that this scheme will allow much more frequent + releases than in the past. + + +====================================================================== + +LATEST CHANGES BETWEEN 2.0.5 and 2.0.4 + + NOTE THAT 2.0.5 DOES NOT CONTAIN THE POSTSCRIPT HINTER. THIS MODULE + WILL BE PART OF THE NEXT RELEASE (EITHER 2.0.6 or 2.1) + + - Fixed a bug that made certain glyphs, like "Cacute", "cacute" and + "lslash" unavailable from Unicode charmaps of Postscript fonts. + This prevented the correct display of Polish text, for example. + + - The kerning table of Type 1 fonts was loaded by FreeType, when its + AFM file was attached to its face, but the + FT_FACE_FLAG_HAS_KERNING bit flags was not set correctly, + preventing FT_Get_Kerning to return meaningful values. + + - Improved SFNT (TrueType & OpenType) charmap support. Slightly + better performance, as well as support for the new formats defined + by the OpenType 1.3 specification (8, 10, and 12) + + - Fixed a serious typo in "src/base/ftcalc.c" which caused invalid + computations in certain rare cases, producing ugly artefacts. + + - The size of the EM square is computed with a more accurate + algorithm for Postscript fonts. The old one caused slight errors + with embedded fonts found in PDF documents. + + - Fixed a bug in the cache manager that prevented normal LRU + behaviour within the cache manager, causing unnecessary reloads + (for FT_Face and FT_Size objects only). + + - Added a new function named "FT_Get_Name_Index" to retrieve the + glyph index of a given glyph name, when found in a face. + + - Added a new function named "FT_Get_Postscript_Name" to retrieve + the "unique" Postscript font name of a given face. + + - Added a new public header size named FT_SIZES_H (or + <freetype/ftsizes.h>) providing new FT_Size-management functions: + FT_New_Size, FT_Activate_Size, FT_Done_Size. + + - Fixed a reallocation bug that generated a dangling pointer (and + possibly memory leaks) with Postscript fonts (in + src/psaux/psobjs.c). + + - Many fixes for 16-bit correctness. + + - Removed many pedantic compiler warnings from the sources. + + - Added an Amiga build directory in "builds/amiga". + + +====================================================================== + +LATEST CHANGES BETWEEN 2.0.4 and 2.0.3 + + - Fixed a rather annoying bug that was introduced in 2.0.3. Namely, + the font transformation set through FT_Set_Transform was applied + twice to auto-hinted glyphs, resulting in incorrectly rotated text + output. + + - Fixed _many_ compiler warnings. FT2 should now compile cleanly + with Visual C++'s most pedantic warning level (/W4). It already + compiled fine with GCC and a few other compilers. + + - Fixed a bug that prevented the linear advance width of composite + TrueType glyphs to be correctly returned. + + - Fixed the Visual C++ project files located in + "builds/win32/visualc" (previous versions used older names of the + library). + + - Many 32-bit constants have an "L" appended to their value, in + order to improve the 16-bitness of the code. Someone is actually + trying to use FT2 on an Atari ST machine! + + - Updated the "builds/detect.mk" file in order to automatically + build FT2 on AIX systems. AIX uses "/usr/sbin/init" instead of + "/sbin/init" and wasn't previously detected as a Unix platform by + the FreeType build system. + + - Updated the Unix-specific portions of the build system (new + libtool version, etc.). + + - The SFNT kerning lodaer now ensures that the table is sorted + (since some problem fonts do not meet this requirement). + + +======================================================================= + +LATEST CHANGES BETWEEN 2.0.3 and 2.0.2 + + I. CHANGES TO THE MODULES / FONT DRIVERS + + - THE AUTO-HINTER HAS BEEN SLIGHTLY IMPROVED, in order to fix + several annoying artefacts, mainly: + + - Blue zone alignement of horizontal stems wasn't performed + correctly, resulting in artefacts like the "d" being placed + one pixel below the "b" in some fonts like Time New Roman. + + - Overshoot thresholding wasn't performed correctly, creating + unpleasant artefacts at large character pixel sizes. + + - Composite glyph loading has been simplified. This gets rid + of various artefacts where the components of a composite + glyphs were not correctly spaced. + + These are the last changes to the current auto-hinting module. + A new hinting sub-system is currently in the work in order to + support native hints in Type 1 / CFF / OpenType fonts, as well + as globally improve rendering. + + - The PCF driver has been fixed. It reported invalid glyph + dimensions for the fonts available on Solaris. + + - The Type 1, CID and CFF drivers have been modified to fix the + computation of the EM size. + + - The Type 1 driver has been fixed to avoid a dangerous bug that + crashed the library with non-conforming fonts (i.e. ones that do + not place the .notdef glyph at position 0). + + - The TrueType driver had a rather subtle bug (dangling pointer + when loading composite glyphs) that could crash the library in + rare occasions! + + + II. HIGH-LEVEL API CHANGES + + - The error code enumeration values have been changed. An error + value is decomposed in a generic error code, and a module + number. see <freetype/fterrors.h> for details. + + - A new public header file has been introduced, named + FT_TRIGONOMETRY_H (include/freetype/fttrig.h), providing + trigonometric functions to compute sines, cosines, arctangents, + etc. with 16.16 fixed precision. The implementation is based on + the CORDIC algorithm and is very fast while being sufficiently + accurate. + + + III. INTERNALS + + - Added BeOS-specific files in the old build sub-system. Note + that no changes were required to compile the library with Jam. + + - The configuration is now capable of automatically detecting + 64-bit integers on a set of predefined compilers (GCC, Visual + C++, Borland C++) and will use them by default. This provides a + small performance boost. + + - A small memory leak that happened when opening 0-sized files + (duh!) have been fixed. + + - Fixed bezier stack depth bug in the routines provided by the + FT_BBOX_H header file. Also fixed similar bugs in the + rasterizers. + + - The outline bounding box code has been rewritten to use direct + computations, instead of bezier sub-division, to compute the + exact bounding box of glyphs. This is slightly slower but more + accurate. + + - The build system has been improved and fixed, mainly to support + "make" on Windows 2000 correctly, avoid problems with "make + distclean" on non Unix systems, etc. + + - Hexadecimal constants have been suffixed with "U" to avoid + problems with certain compilers on 64-bit platforms. + + - A new directory named "src/tools" has been created. It contains + Python scripts and simple unit test programs used to develop the + library. + + - The DocMaker tool has been moved from "docs" to "src/tools" and + has been updated with the following: + + - Now accepts the "--title=XXXX" or "-t XXXX" option from the + command line to set the project's name in the generated API + reference. + + - Now accepts the "--output=DIR" or "-o DIR" option from the + command line to set the output directory for all generated + HTML files. + + - Now accepts the "--prefix=XXXX" or "-p XXX" option from the + command line to set the file prefix to use for all + generated HTML files. + + - Now generates the current time/data on each generated page + in order to distinguish between versions. + + DocMaker can be used with other projects now, not only FT2 + (e.g. MLib, FTLayout, etc.). + + +====================================================================== + +LATEST CHANGES BETWEEN 2.0.2 and 2.0.1 + + I. CHANGES TO THE MODULES / FONT DRIVERS + + - THE TRUETYPE BYTECODE INTERPRETER IS NOW TURNED OFF, in order to + avoid legal problems with the Apple patents. It seems that we + mistakenly turned this option on in previous releases of the + build. + + Note that if you want to use the bytecode interpreter in order + to get high-quality TrueType rendering, you will need to toggle + by hand the definition of the + TT_CONFIG_OPTION_BYTECODE_INTERPRETER macro in the file + "include/freetype/config/ftoption.h". + + - The CFF driver has been improved by Tom Kacvinsky and Sander van + der Wal: + + * Support for "seac" emulation. + * Support for "dotsection". + * Support for retrieving glyph names through + "FT_Get_Glyph_Name". + + The first two items are necessary to correctly a large number of + Type 1 fonts converted to the CFF formats by Adobe Acrobat. + + - The Type 1 driver was also improved by Tom & others: + + * Better EM size computation. + * Better support for synthetic (transformed) fonts. + * The Type 1 driver returns the charstrings corresponding to + each glyph in the "glyph->control_data" field after a call to + "FT_Load_Glyph" (thanks Ha Shao). + + - Various other bugfixes, including the following: + + * Fixed a nasty memory leak in the Type 1 driver. + * The autohinter and the pcf driver used static writable data + when they shouldn't. + * Many casts were added to make the code more 64-bits safe. It + also now compiles on Windows XP 64-bits without warnings. + * Some incorrect writable statics were removed in the "autohint" + and "pcf" drivers. FreeType 2 now compiles on Epoc again. + + + II. CHANGES TO THE HIGH-LEVEL API + + - The library header files inclusion scheme has been changed. The + old scheme looked like: + + #include <freetype/freetype.h> + #include <freetype/ftglyph.h> + #include <freetype/ftcache.h> + #include <freetype/cache/ftimage.h> + + Now you should use: + + #include <ft2build.h> + #include FT_FREETYPE_H + #include FT_GLYPH_H + #include FT_CACHE_H + #include FT_CACHE_IMAGE_H + + NOTE THAT THE OLD INCLUSION SCHEME WILL STILL WORK WITH THIS + RELEASE. HOWEVER, WE DO NOT GUARANTEE THAT THIS WILL STILL BE + TRUE IN THE NEXT ONE (A.K.A. FREETYPE 2.1). + + The file <ft2build.h> is used to define the header filename + macros. The complete and commented list of macros is available + in the API reference under the section name "Header File Macros" + in Chapter I. + + For more information, see section I of the following document: + + http://www.freetype.org/ + freetype2/docs/tutorial/step1.html + + or + + http://freetype.sourceforge.net/ + freetype2/docs/tutorial/step1.html + + - Many, many comments have been added to the public source file in + order to automatically generate the API Reference through the + "docmaker.py" Python script. + + The latter has been updated to support the grouping of sections + in chapters and better index sort. See: + + http://www.freetype.org/freetype2/docs/reference/ft2-toc.html + + + III. CHANGES TO THE BUILD PROCESS + + - If you are not building FreeType 2 with its own build system + (but with your own Makefiles or project files), you will need to + be aware that the build process has changed a little bit. + + You don't need to put the "src" directory in the include path + when compiling any FT2 component. Instead, simply put the + component's directory in the current include path. + + So, if you were doing something like: + + cc -c -Iinclude -Isrc src/base/ftbase.c + + change the line to: + + cc -c -Iinclude -Isrc/base src/base/ftbase.c + + If you were doing something like: + + cd src/base + cc -c -I../../include -I.. ftbase.c + + change it to: + + cd src/base + cc -c -I../../include ftbase.c + + +====================================================================== + +LATEST CHANGES BETWEEN 2.0.1 and 2.0 + + 2.0.1 introduces a few changes: + + - Fixed many bugs related to the support of CFF / OpenType fonts. + These formats are now much better supported though there is + still work planned to deal with charset tables and PDF-embedded + CFF files that use the old "seac" command. + + - The library could not be compiled in debug mode with a very + small number of C compilers whose pre-processors didn't + implement the "##" directive correctly (i.e. per se the ANSI C + specification!) An elegant fix was found. + + - Added support for the free Borland command-line C++ Builder + compiler. Use "make setup bcc32". Also fixed a few source + lines that generated new warnings with BCC32. + + - Fixed a bug in FT_Outline_Get_BBox when computing the extrema of + a conic Bezier arc. + + - Updated the INSTALL file to add IDE compilation. + + - Other minor bug fixes, from invalid Type 1 style flags to + correct support of synthetic (obliqued) fonts in the + auto-hinter, better support for embedded bitmaps in a SFNT font. + + - Fixed some problems with "freetype-config". + + Finally, the "standard" scheme for including FreeType headers is now + gradually changing, but this will be explained in a later release + (probably 2.0.2). + + And very special thanks to Tom Kacvinsky and YAMANO-UCHI Hidetoshi + for their contributions! + + +====================================================================== + +CHANGES BETWEEN beta8 and 2.0 + + - Changed the default installation path for public headers from + "include/freetype" to "include/freetype2". + + Also added a new "freetype-config" that is automatically generated + and installed on Unix and Cygwin systems. The script itself is + used to retrieve the current install path, C compilation flags as + well as linker flags. + + - Fixed several small bugs: + + * Incorrect max advance width for fixed-pitch Type 1 fonts. + * Incorrect glyph names for certain TrueType fonts. + * The glyph advance was not copied when FT_Glyph_To_Bitmap was + called. + * The linearHoriAdvance and linerVertAdvance fields were not + correctly returned for glyphs processed by the auto-hinter. + * "type1z" renamed back to "type1"; the old "type1" module has + been removed. + + - Revamped the build system to make it a lot more generic. This + will allow us to re-use nearly un-modified in lots of other + projects (including FreeType Layout). + + - Changed "cid" to use "psaux" too. + + - Added the cache sub-system. See <freetype/ftcache.h> as well as + the sources in "src/cache". Note that it compiles but is still + untested for now. + + - Updated "docs/docmaker.py", a draft API reference is available at + http://www.freetype.org/ft2api.html. + + - Changed "type1" to use "psaux". + + - Created a new module named "psaux" to hold the Type 1 & Type 2 + parsing routines. It should be used by "type1", "cid", and "cff" + in the future. + + - Fixed an important bug in "FT_Glyph_Get_CBox". + + - Fixed some compiler warnings that happened since the TrueType + bytecode decoder was deactivated by default. + + - Fixed two memory leaks: + + * The memory manager (16 bytes) isn't released in + FT_Done_FreeType! + * Using custom input streams, the copy of the original stream was + never released. + + - Fixed the auto-hinter by performing automatic computation of the + "filling direction" of each glyph. This is done through a simple + and fast approximation, and seems to work (problems spotted by + Werner though). The Arphic fonts are a lot nicer though there are + still a lot of things to do to handle Asian fonts correctly. + + +====================================================================== + +BETA-8 (RELEASE CANDIDATE) 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 is 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 + + * FT_Get_Kerning has a new parameter that allows you to select the + coordinates of the kerning vector (font units, scaled, scaled + + grid-fitted). + * The outline functions are now in <freetype/ftoutln.h> and not + part of <freetype/freetype.h> anymore. + * <freetype/ftmodule.h> now contains declarations for + FT_New_Library, FT_Done_Library, FT_Add_Default_Modules. + * 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. + * 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. + * <freetype/freetype.h> now include <freetype/config/ftconfig.h>, + solving a few headaches :-) + * 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 initialization, 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. + + he 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 has 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 + IF 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 IF 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. + + - Reformatted 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. + + - 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_DIR + 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_DIR 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. + + +====================================================================== + +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); + } + +--- end of CHANGES --- diff --git a/nx-X11/extras/freetype2/docs/CUSTOMIZE b/nx-X11/extras/freetype2/docs/CUSTOMIZE new file mode 100644 index 000000000..8709b3dec --- /dev/null +++ b/nx-X11/extras/freetype2/docs/CUSTOMIZE @@ -0,0 +1,125 @@ +How to customize the compilation of the library: +================================================ + + FreeType is highly customizable to fit various needs, and this + document describes how it is possible to select options and components + at compilation time. + + +I. Configuration macros + + The file found in "include/freetype/config/ftoption.h" contains a list + of commented configuration macros that can be toggled by developers to + indicate which features should be active while building the library. + + These options range from debug level to availability of certain + features, like native TrueType hinting through a bytecode interpreter. + + We invite you to read this file for more information. You can change + the file's content to suit your needs, or override it with one of the + techniques described below. + + +II. Modules list + + The file found in "include/freetype/config/ftmodule.h" contains a list + of names corresponding to the modules and font drivers to be + statically compiled in the FreeType library during the build. + + You can change it to suit your own preferences. Be aware that certain + modules depend on others, as described by the file "modules.txt" in + this directory. + + You can modify the file's content to suit your needs, or override it + at compile time with one of the methods described below. + + +III. System interface + + FreeType's default interface to the system (i.e., the parts that deal + with memory management and i/o streams) is located in + "src/base/ftsystem.c". + + The current implementation uses standard C library calls to manage + memory and to read font files. It is however possible to write custom + implementations to suit specific systems. + + To tell the GNU Make-based build system to use a custom system + interface, you have to define the environment variable FTSYS_SRC to + point to the relevant implementation: + + on Unix: + + ./configure <your options> + export FTSYS_SRC=foo/my_ftsystem.c + make + make install + + on Windows: + + make setup <compiler> + set FTSYS_SRC=foo/my_ftsystem.c + make + + +IV. Overriding default configuration and module headers + + It is possible to override the default configuration and module + headers without changing the original files. There are two ways to do + that: + + + 1. Using the C include path + + Use the C include path to ensure that your own versions of the files + are used at compile time when the lines + + #include FT_CONFIG_OPTIONS_H + #include FT_CONFIG_MODULES_H + + are compiled. Their default values being + <freetype/config/ftoption.h> and <freetype/config/ftmodule.h>, you + can do something like: + + custom/ + freetype/ + config/ + ftoption.h => custom options header + ftmodule.h => custom modules list + + include/ => normal FreeType 2 include + freetype/ + ... + + then change the C include path to always give the path to "custom" + before the FreeType 2 "include". + + + 2. Re-defining FT_CONFIG_OPTIONS_H and FT_CONFIG_MODULES_H + + Another way to do the same thing is to redefine the macros used to + name the configuration headers. To do so, you need a custom + "ft2build.h" whose content can be as simple as: + + #ifndef __FT2_BUILD_MY_PLATFORM_H__ + #define __FT2_BUILD_MY_PLATFORM_H__ + + #define FT_CONFIG_OPTIONS_H <custom/my-ftoption.h> + #define FT_CONFIG_MODULES_H <custom/my-ftmodule.h> + + #include <freetype/config/ftheader.h> + + #endif /* __FT2_BUILD_MY_PLATFORM_H__ */ + + Place those files in a separate directory, e.g.: + + custom/ + ft2build.h => custom version described above + my-ftoption.h => custom options header + my-ftmodule.h => custom modules list header + + and change the C include path to ensure that "custom" is always + placed before the FT2 "include" during compilation. + + +--- end of CUSTOMIZE --- diff --git a/nx-X11/extras/freetype2/docs/DEBUG b/nx-X11/extras/freetype2/docs/DEBUG new file mode 100644 index 000000000..c85ef3cb1 --- /dev/null +++ b/nx-X11/extras/freetype2/docs/DEBUG @@ -0,0 +1,183 @@ +Debugging within the FreeType sources +===================================== + +I. Configuration macros +----------------------- + +There are several ways to enable debugging features in a FreeType 2 +builds. This is controlled through the definition of special macros +located in the file "ftoptions.h". The macros are: + + + FT_DEBUG_LEVEL_ERROR + + #define this macro if you want to compile the FT_ERROR macro calls + to print error messages during program execution. This will not + stop the program. Very useful to spot invalid fonts during + development and to code workarounds for them. + + FT_DEBUG_LEVEL_TRACE + + #define this macro if you want to compile both macros FT_ERROR and + FT_TRACE. This also includes the variants FT_TRACE0, FT_TRACE1, + FT_TRACE2, ..., FT_TRACE6. + + The trace macros are used to send debugging messages when an + appropriate "debug level" is configured at runtime through the + FT2_DEBUG environment variable (more on this later). + + FT_DEBUG_MEMORY + + If this macro is #defined, the FreeType engine is linked with a + small but effective debugging memory manager that tracks all + allocations and frees that are performed within the font engine. + + When the FT2_DEBUG_MEMORY environment variable is defined at + runtime, a call to FT_Done_FreeType will dump memory statistics, + including the list of leaked memory blocks with the source locations + where these were allocated. It is always a very good idea to define + this in development builds. This works with _any_ program linked to + FreeType, but requires a big deal of memory (the debugging memory + manager never frees the blocks to the heap in order to detect double + frees). + + When FT2_DEBUG_MEMORY isn't defined at runtime, the debugging memory + manager is ignored, and performance is unaffected. + + +II. Debugging macros +-------------------- + +Several macros can be used within the FreeType sources to help debugging +its code: + + 1. FT_ERROR(( ... )) + + This macro is used to send debug messages that indicate relatively + serious errors (like broken font files), but will not stop the + execution of the running program. Its code is compiled only when + either FT_DEBUG_LEVEL_ERROR or FT_DEBUG_LEVEL_TRACE are defined in + "ftoption.h". + + Note that you have to use a printf-like signature, but with double + parentheses, like in: + + FT_ERROR(( "your %s is not %s\n", "foo", "bar" )); + + + 2. FT_ASSERT( condition ) + + This macro is used to check strong assertions at runtime. If its + condition isn't TRUE, the program will abort with a panic message. + Its code is compiled when either FT_DEBUG_LEVEL_ERROR or + FT_DEBUG_LEVEL_TRACE are defined. You don't need double-parentheses + here. For example: + + FT_ASSERT( ptr != NULL ); + + + 3. FT_TRACE( level, (message...) ) + + The FT_TRACE macro is used to send general-purpose debugging + messages during program execution. This macro uses an *implicit* + macro named FT_COMPONENT used to name the current FreeType component + being run. + + The developer should always define FT_COMPONENT as appropriate, for + example as in: + + #undef FT_COMPONENT + #define FT_COMPONENT trace_io + + The value of the FT_COMPONENT macro is an enumeration named + trace_XXXX where XXXX is one of the component names defined in the + internal file <freetype/internal/fttrace.h>. + + Each such component is assigned a "debug level", ranging from 0 + to 6, through the use of the FT2_DEBUG environment variable + (described below) when a program linked with FreeType starts. + + When FT_TRACE is called, its level is compared to the one of the + corresponding component. Messages with trace levels *higher* than + the corresponding component level are filtered and never printed. + + This means that trace messages with level 0 are always printed, + those with level 2 are only printed when the component level is *at + least* 2. + + The second parameter to FT_TRACE must contain parentheses and + correspond to a printf-like call, as in: + + FT_TRACE( 2, ( "your %s is not %s\n", "foo", "bar" ) ) + + The shortcut macros FT_TRACE0, FT_TRACE1, FT_TRACE2_, ... FT_TRACE6 + can be used with constant level indices, and are much cleaner to + use, as in + + FT_TRACE2(( "your %s is not %s\n", "foo", "bar" )); + + +III. Environment variables +-------------------------- + +The following environment variables control debugging output and +behaviour of FreeType at runtime: + + FT2_DEBUG + + This variable is only used when FreeType is built with + FT_DEBUG_LEVEL_TRACE defined. It contains a list of component level + definitions, following this format: + + component1:level1 component2:level2 component3:level3 ... + + where "componentX" is the name of a tracing component, as defined in + "fttrace.h", but without the "trace_" prefix. "levelX" is the + corresponding level to use at runtime. + + "any" is a special component name that will be interpreted as + "any/all components". For example, the following definitions + + set FT2_DEBUG=any:2 memory:5 io:4 (on Windows) + export FT2_DEBUG="any:2 memory:5 io:4" (on Linux with bash) + + both stipulate that all components should have level 2, except for + the memory and io components which will be set to trace levels 5 + and 4, respectively. + + FT2_DEBUG_MEMORY + + This environment variable, when defined, tells FreeType to use a + debugging memory manager that will track leaking memory blocks as + well as other common errors like double frees. It is also capable + of reporting _where_ the leaking blocks were allocated, which + considerably saves time when debugging new additions to the library. + + This code is only compiled when FreeType is built with the + FT_DEBUG_MEMORY macro #defined in "ftoption.h" though, it will be + ignored in other builds. + + FT2_ALLOC_TOTAL_MAX + + This variable is ignored if FT2_DEBUG_MEMORY is not defined. It + allows you to specify a maximum heap size for all memory allocations + performed by FreeType. This is very useful to test the robustness + of the font engine and programs that use it in tight memory + conditions. + + If it is undefined, or if its value is not strictly positive, then + no allocation bounds are checked at runtime. + + FT2_ALLOC_COUNT_MAX + + This variable is ignored if FT2_DEBUG_MEMORY is not defined. It + allows you to specify a maximum number of memory allocations + performed by FreeType before returning the error + FT_Err_Out_Of_Memory. This is useful for debugging and testing the + engine's robustness. + + If it is undefined, or if its value is not strictly positive, then + no allocation bounsd are checked at runtime. + + +--- end of DEBUG --- diff --git a/nx-X11/extras/freetype2/docs/FTL.txt b/nx-X11/extras/freetype2/docs/FTL.txt new file mode 100644 index 000000000..096730273 --- /dev/null +++ b/nx-X11/extras/freetype2/docs/FTL.txt @@ -0,0 +1,174 @@ + The FreeType Project LICENSE + ---------------------------- + + 2002-Apr-11 + + Copyright 1996-2002 by + David Turner, Robert Wilhelm, and Werner Lemberg + + + +Introduction +============ + + The FreeType Project is distributed in several archive packages; + some of them may contain, in addition to the FreeType font engine, + various tools and contributions which rely on, or relate to, the + FreeType Project. + + This license applies to all files found in such packages, and + which do not fall under their own explicit license. The license + affects thus the FreeType font engine, the test programs, + documentation and makefiles, at the very least. + + This license was inspired by the BSD, Artistic, and IJG + (Independent JPEG Group) licenses, which all encourage inclusion + and use of free software in commercial and freeware products + alike. As a consequence, its main points are that: + + o We don't promise that this software works. However, we will be + interested in any kind of bug reports. (`as is' distribution) + + o You can use this software for whatever you want, in parts or + full form, without having to pay us. (`royalty-free' usage) + + o You may not pretend that you wrote this software. If you use + it, or only parts of it, in a program, you must acknowledge + somewhere in your documentation that you have used the + FreeType code. (`credits') + + We specifically permit and encourage the inclusion of this + software, with or without modifications, in commercial products. + We disclaim all warranties covering The FreeType Project and + assume no liability related to The FreeType Project. + + + Finally, many people asked us for a preferred form for a + credit/disclaimer to use in compliance with this license. We thus + encourage you to use the following text: + + """ + Portions of this software are copyright Š 1996-2002 The FreeType + Project (www.freetype.org). All rights reserved. + """ + + +Legal Terms +=========== + +0. Definitions +-------------- + + Throughout this license, the terms `package', `FreeType Project', + and `FreeType archive' refer to the set of files originally + distributed by the authors (David Turner, Robert Wilhelm, and + Werner Lemberg) as the `FreeType Project', be they named as alpha, + beta or final release. + + `You' refers to the licensee, or person using the project, where + `using' is a generic term including compiling the project's source + code as well as linking it to form a `program' or `executable'. + This program is referred to as `a program using the FreeType + engine'. + + This license applies to all files distributed in the original + FreeType Project, including all source code, binaries and + documentation, unless otherwise stated in the file in its + original, unmodified form as distributed in the original archive. + If you are unsure whether or not a particular file is covered by + this license, you must contact us to verify this. + + The FreeType Project is copyright (C) 1996-2000 by David Turner, + Robert Wilhelm, and Werner Lemberg. All rights reserved except as + specified below. + +1. No Warranty +-------------- + + THE FREETYPE PROJECT IS PROVIDED `AS IS' WITHOUT WARRANTY OF ANY + KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, + WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR + PURPOSE. IN NO EVENT WILL ANY OF THE AUTHORS OR COPYRIGHT HOLDERS + BE LIABLE FOR ANY DAMAGES CAUSED BY THE USE OR THE INABILITY TO + USE, OF THE FREETYPE PROJECT. + +2. Redistribution +----------------- + + This license grants a worldwide, royalty-free, perpetual and + irrevocable right and license to use, execute, perform, compile, + display, copy, create derivative works of, distribute and + sublicense the FreeType Project (in both source and object code + forms) and derivative works thereof for any purpose; and to + authorize others to exercise some or all of the rights granted + herein, subject to the following conditions: + + o Redistribution of source code must retain this license file + (`FTL.TXT') unaltered; any additions, deletions or changes to + the original files must be clearly indicated in accompanying + documentation. The copyright notices of the unaltered, + original files must be preserved in all copies of source + files. + + o Redistribution in binary form must provide a disclaimer that + states that the software is based in part of the work of the + FreeType Team, in the distribution documentation. We also + encourage you to put an URL to the FreeType web page in your + documentation, though this isn't mandatory. + + These conditions apply to any software derived from or based on + the FreeType Project, not just the unmodified files. If you use + our work, you must acknowledge us. However, no fee need be paid + to us. + +3. Advertising +-------------- + + Neither the FreeType authors and contributors nor you shall use + the name of the other for commercial, advertising, or promotional + purposes without specific prior written permission. + + We suggest, but do not require, that you use one or more of the + following phrases to refer to this software in your documentation + or advertising materials: `FreeType Project', `FreeType Engine', + `FreeType library', or `FreeType Distribution'. + + As you have not signed this license, you are not required to + accept it. However, as the FreeType Project is copyrighted + material, only this license, or another one contracted with the + authors, grants you the right to use, distribute, and modify it. + Therefore, by using, distributing, or modifying the FreeType + Project, you indicate that you understand and accept all the terms + of this license. + +4. Contacts +----------- + + There are two mailing lists related to FreeType: + + o freetype@freetype.org + + Discusses general use and applications of FreeType, as well as + future and wanted additions to the library and distribution. + If you are looking for support, start in this list if you + haven't found anything to help you in the documentation. + + o devel@freetype.org + + Discusses bugs, as well as engine internals, design issues, + specific licenses, porting, etc. + + o http://www.freetype.org + + Holds the current FreeType web page, which will allow you to + download our latest development version and read online + documentation. + + You can also contact us individually at: + + David Turner <david.turner@freetype.org> + Robert Wilhelm <robert.wilhelm@freetype.org> + Werner Lemberg <werner.lemberg@freetype.org> + + +--- end of LICENSE.TXT --- diff --git a/nx-X11/extras/freetype2/docs/GPL.txt b/nx-X11/extras/freetype2/docs/GPL.txt new file mode 100644 index 000000000..e8a612e5c --- /dev/null +++ b/nx-X11/extras/freetype2/docs/GPL.txt @@ -0,0 +1,339 @@ + GNU GENERAL PUBLIC LICENSE + Version 2, June 1991 + + Copyright (C) 1989, 1990, 1991, 1992 Free Software Foundation, Inc. + 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA + Everyone is permitted to copy and distribute verbatim copies + of this license document, but changing it is not allowed. + + Preamble + + The licenses for most software are designed to take away your +freedom to share and change it. By contrast, the GNU General Public +License is intended to guarantee your freedom to share and change free +software--to make sure the software is free for all its users. This +General Public License applies to most of the Free Software +Foundation's software and to any other program whose authors commit to +using it. (Some other Free Software Foundation software is covered by +the GNU Library General Public License instead.) You can apply it to +your programs, too. + + When we speak of free software, we are referring to freedom, not +price. Our General Public Licenses are designed to make sure that you +have the freedom to distribute copies of free software (and charge for +this service if you wish), that you receive source code or can get it +if you want it, that you can change the software or use pieces of it +in new free programs; and that you know you can do these things. + + To protect your rights, we need to make restrictions that forbid +anyone to deny you these rights or to ask you to surrender the rights. +These restrictions translate to certain responsibilities for you if you +distribute copies of the software, or if you modify it. + + For example, if you distribute copies of such a program, whether +gratis or for a fee, you must give the recipients all the rights that +you have. You must make sure that they, too, receive or can get the +source code. And you must show them these terms so they know their +rights. + + We protect your rights with two steps: (1) copyright the software, and +(2) offer you this license which gives you legal permission to copy, +distribute and/or modify the software. + + Also, for each author's protection and ours, we want to make certain +that everyone understands that there is no warranty for this free +software. If the software is modified by someone else and passed on, we +want its recipients to know that what they have is not the original, so +that any problems introduced by others will not reflect on the original +authors' reputations. + + Finally, any free program is threatened constantly by software +patents. We wish to avoid the danger that redistributors of a free +program will individually obtain patent licenses, in effect making the +program proprietary. To prevent this, we have made it clear that any +patent must be licensed for everyone's free use or not licensed at all. + + The precise terms and conditions for copying, distribution and +modification follow. + + GNU GENERAL PUBLIC LICENSE + TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION + + 0. This License applies to any program or other work which contains +a notice placed by the copyright holder saying it may be distributed +under the terms of this General Public License. The "Program", below, +refers to any such program or work, and a "work based on the Program" +means either the Program or any derivative work under copyright law: +that is to say, a work containing the Program or a portion of it, +either verbatim or with modifications and/or translated into another +language. (Hereinafter, translation is included without limitation in +the term "modification".) Each licensee is addressed as "you". + +Activities other than copying, distribution and modification are not +covered by this License; they are outside its scope. The act of +running the Program is not restricted, and the output from the Program +is covered only if its contents constitute a work based on the +Program (independent of having been made by running the Program). +Whether that is true depends on what the Program does. + + 1. You may copy and distribute verbatim copies of the Program's +source code as you receive it, in any medium, provided that you +conspicuously and appropriately publish on each copy an appropriate +copyright notice and disclaimer of warranty; keep intact all the +notices that refer to this License and to the absence of any warranty; +and give any other recipients of the Program a copy of this License +along with the Program. + +You may charge a fee for the physical act of transferring a copy, and +you may at your option offer warranty protection in exchange for a fee. + + 2. You may modify your copy or copies of the Program or any portion +of it, thus forming a work based on the Program, and copy and +distribute such modifications or work under the terms of Section 1 +above, provided that you also meet all of these conditions: + + a) You must cause the modified files to carry prominent notices + stating that you changed the files and the date of any change. + + b) You must cause any work that you distribute or publish, that in + whole or in part contains or is derived from the Program or any + part thereof, to be licensed as a whole at no charge to all third + parties under the terms of this License. + + c) If the modified program normally reads commands interactively + when run, you must cause it, when started running for such + interactive use in the most ordinary way, to print or display an + announcement including an appropriate copyright notice and a + notice that there is no warranty (or else, saying that you provide + a warranty) and that users may redistribute the program under + these conditions, and telling the user how to view a copy of this + License. (Exception: if the Program itself is interactive but + does not normally print such an announcement, your work based on + the Program is not required to print an announcement.) + +These requirements apply to the modified work as a whole. If +identifiable sections of that work are not derived from the Program, +and can be reasonably considered independent and separate works in +themselves, then this License, and its terms, do not apply to those +sections when you distribute them as separate works. But when you +distribute the same sections as part of a whole which is a work based +on the Program, the distribution of the whole must be on the terms of +this License, whose permissions for other licensees extend to the +entire whole, and thus to each and every part regardless of who wrote it. + +Thus, it is not the intent of this section to claim rights or contest +your rights to work written entirely by you; rather, the intent is to +exercise the right to control the distribution of derivative or +collective works based on the Program. + +In addition, mere aggregation of another work not based on the Program +with the Program (or with a work based on the Program) on a volume of +a storage or distribution medium does not bring the other work under +the scope of this License. + + 3. You may copy and distribute the Program (or a work based on it, +under Section 2) in object code or executable form under the terms of +Sections 1 and 2 above provided that you also do one of the following: + + a) Accompany it with the complete corresponding machine-readable + source code, which must be distributed under the terms of Sections + 1 and 2 above on a medium customarily used for software interchange; or, + + b) Accompany it with a written offer, valid for at least three + years, to give any third party, for a charge no more than your + cost of physically performing source distribution, a complete + machine-readable copy of the corresponding source code, to be + distributed under the terms of Sections 1 and 2 above on a medium + customarily used for software interchange; or, + + c) Accompany it with the information you received as to the offer + to distribute corresponding source code. (This alternative is + allowed only for noncommercial distribution and only if you + received the program in object code or executable form with such + an offer, in accord with Subsection b above.) + +The source code for a work means the preferred form of the work for +making modifications to it. For an executable work, complete source +code means all the source code for all modules it contains, plus any +associated interface definition files, plus the scripts used to +control compilation and installation of the executable. However, as a +special exception, the source code distributed need not include +anything that is normally distributed (in either source or binary +form) with the major components (compiler, kernel, and so on) of the +operating system on which the executable runs, unless that component +itself accompanies the executable. + +If distribution of executable or object code is made by offering +access to copy from a designated place, then offering equivalent +access to copy the source code from the same place counts as +distribution of the source code, even though third parties are not +compelled to copy the source along with the object code. + + 4. You may not copy, modify, sublicense, or distribute the Program +except as expressly provided under this License. Any attempt +otherwise to copy, modify, sublicense or distribute the Program is +void, and will automatically terminate your rights under this License. +However, parties who have received copies, or rights, from you under +this License will not have their licenses terminated so long as such +parties remain in full compliance. + + 5. You are not required to accept this License, since you have not +signed it. However, nothing else grants you permission to modify or +distribute the Program or its derivative works. These actions are +prohibited by law if you do not accept this License. Therefore, by +modifying or distributing the Program (or any work based on the +Program), you indicate your acceptance of this License to do so, and +all its terms and conditions for copying, distributing or modifying +the Program or works based on it. + + 6. Each time you redistribute the Program (or any work based on the +Program), the recipient automatically receives a license from the +original licensor to copy, distribute or modify the Program subject to +these terms and conditions. You may not impose any further +restrictions on the recipients' exercise of the rights granted herein. +You are not responsible for enforcing compliance by third parties to +this License. + + 7. If, as a consequence of a court judgment or allegation of patent +infringement or for any other reason (not limited to patent issues), +conditions are imposed on you (whether by court order, agreement or +otherwise) that contradict the conditions of this License, they do not +excuse you from the conditions of this License. If you cannot +distribute so as to satisfy simultaneously your obligations under this +License and any other pertinent obligations, then as a consequence you +may not distribute the Program at all. For example, if a patent +license would not permit royalty-free redistribution of the Program by +all those who receive copies directly or indirectly through you, then +the only way you could satisfy both it and this License would be to +refrain entirely from distribution of the Program. + +If any portion of this section is held invalid or unenforceable under +any particular circumstance, the balance of the section is intended to +apply and the section as a whole is intended to apply in other +circumstances. + +It is not the purpose of this section to induce you to infringe any +patents or other property right claims or to contest validity of any +such claims; this section has the sole purpose of protecting the +integrity of the free software distribution system, which is +implemented by public license practices. Many people have made +generous contributions to the wide range of software distributed +through that system in reliance on consistent application of that +system; it is up to the author/donor to decide if he or she is willing +to distribute software through any other system and a licensee cannot +impose that choice. + +This section is intended to make thoroughly clear what is believed to +be a consequence of the rest of this License. + + 8. If the distribution and/or use of the Program is restricted in +certain countries either by patents or by copyrighted interfaces, the +original copyright holder who places the Program under this License +may add an explicit geographical distribution limitation excluding +those countries, so that distribution is permitted only in or among +countries not thus excluded. In such case, this License incorporates +the limitation as if written in the body of this License. + + 9. The Free Software Foundation may publish revised and/or new versions +of the General Public License from time to time. Such new versions will +be similar in spirit to the present version, but may differ in detail to +address new problems or concerns. + +Each version is given a distinguishing version number. If the Program +specifies a version number of this License which applies to it and "any +later version", you have the option of following the terms and conditions +either of that version or of any later version published by the Free +Software Foundation. If the Program does not specify a version number of +this License, you may choose any version ever published by the Free Software +Foundation. + + 10. If you wish to incorporate parts of the Program into other free +programs whose distribution conditions are different, write to the author +to ask for permission. For software which is copyrighted by the Free +Software Foundation, write to the Free Software Foundation; we sometimes +make exceptions for this. Our decision will be guided by the two goals +of preserving the free status of all derivatives of our free software and +of promoting the sharing and reuse of software generally. + + NO WARRANTY + + 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY +FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN +OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES +PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED +OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF +MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS +TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE +PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, +REPAIR OR CORRECTION. + + 12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING +WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR +REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, +INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING +OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED +TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY +YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER +PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE +POSSIBILITY OF SUCH DAMAGES. + + END OF TERMS AND CONDITIONS + + Appendix: How to Apply These Terms to Your New Programs + + If you develop a new program, and you want it to be of the greatest +possible use to the public, the best way to achieve this is to make it +free software which everyone can redistribute and change under these terms. + + To do so, attach the following notices to the program. It is safest +to attach them to the start of each source file to most effectively +convey the exclusion of warranty; and each file should have at least +the "copyright" line and a pointer to where the full notice is found. + + <one line to give the program's name and a brief idea of what it does.> + Copyright (C) 19yy <name of author> + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 2 of the License, or + (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program; if not, write to the Free Software + Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + +Also add information on how to contact you by electronic and paper mail. + +If the program is interactive, make it output a short notice like this +when it starts in an interactive mode: + + Gnomovision version 69, Copyright (C) 19yy name of author + Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'. + This is free software, and you are welcome to redistribute it + under certain conditions; type `show c' for details. + +The hypothetical commands `show w' and `show c' should show the appropriate +parts of the General Public License. Of course, the commands you use may +be called something other than `show w' and `show c'; they could even be +mouse-clicks or menu items--whatever suits your program. + +You should also get your employer (if you work as a programmer) or your +school, if any, to sign a "copyright disclaimer" for the program, if +necessary. Here is a sample; alter the names: + + Yoyodyne, Inc., hereby disclaims all copyright interest in the program + `Gnomovision' (which makes passes at compilers) written by James Hacker. + + <signature of Ty Coon>, 1 April 1989 + Ty Coon, President of Vice + +This General Public License does not permit incorporating your program into +proprietary programs. If your program is a subroutine library, you may +consider it more useful to permit linking proprietary applications with the +library. If this is what you want to do, use the GNU Library General +Public License instead of this License. diff --git a/nx-X11/extras/freetype2/docs/INSTALL b/nx-X11/extras/freetype2/docs/INSTALL new file mode 100644 index 000000000..8fb665759 --- /dev/null +++ b/nx-X11/extras/freetype2/docs/INSTALL @@ -0,0 +1,67 @@ + +There are several ways to build the FreeType library, depending on your +system and the level of customization you need. Here is a short +overview of the documentation available: + + +I. Normal installation and upgrades +=================================== + + 1. Native TrueType Hinting + + Native TrueType hinting is disabled by default[1]. If you really + need it, read the file "TRUETYPE" for information. + + 2. Unix Systems (as well as Cygwin or MSys on Windows) + + Please read *both* UPGRADE.UNX and INSTALL.UNX to install or upgrade + FreeType 2 on a Unix system. Note that you *will* need GNU Make, + since other make tools won't work (this includes BSD Make). + + 3. On VMS with the "mms" build tool + + See INSTALL.VMS for installation instructions on this platform. + + 4. Other systems using GNU Make + + On non-Unix platforms, it is possible to build the library using GNU + Make utility. Note that *NO OTHER MAKE TOOL WILL WORK*[2]! This + methods supports several compilers on Windows, OS/2, and BeOS, + including Mingw, Visual C++, Borland C++, and more. + + Instructions are provided in the file "INSTALL.GNU". + + 5. With an IDE Project File (e.g. for Visual Studio or CodeWarrior) + + We provide a small number of "project files" for various IDEs to + automatically build the library as well. Note that these files are + not supported and sporadically maintained by FreeType developers, so + don't expect them to work in each release. + + To find them, have a look at the content of the "builds/<system>" + directory, where <system> stands for your OS or environment. + + 6. From you own IDE, or own Makefiles + + If you want to create your own project file, follow the instructions + given in the "INSTALL.ANY" document of this directory. + + +II. Custom builds of the library +================================ + + Customizing the compilation of FreeType is easy, and allows you to + select only the components of the font engine that you really need. + For more details read the file "CUSTOMIZE". + + +------------------------------------------------------------------------ + +[1] More details on: http://www.freetype.org/patents.html + +[2] make++, a make tool written in Perl, has sufficient support of GNU + make extensions to build FreeType. See + http://makepp.sourceforge.net for more information; you need version + 1.19 or newer, and you must pass option `--norc-substitution'. + +--- end of INSTALL --- diff --git a/nx-X11/extras/freetype2/docs/INSTALL.ANY b/nx-X11/extras/freetype2/docs/INSTALL.ANY new file mode 100644 index 000000000..af3f6e7a3 --- /dev/null +++ b/nx-X11/extras/freetype2/docs/INSTALL.ANY @@ -0,0 +1,99 @@ +Instructions on how to build FreeType with your own build tool +============================================================== + +See the file "CUSTOMIZE" to learn how to customize FreeType to specific +environments. + + +I. Standard procedure +--------------------- + + * DISABLE PRE-COMPILED HEADERS! This is very important for Visual + C++, because FreeType uses lines like: + + #include FT_FREETYPE_H + + which are not correctly supported by this compiler while being ISO C + compliant! + + * You need to add the directories "freetype2/include" to your include + path when compiling the library. + + * FreeType 2 is made of several components; each of them is located in + a subdirectory of "freetype2/src". For example, + 'freetype2/src/truetype/' contains the TrueType font driver. + + * DO NOT COMPILE ALL C FILES! Rather, compile the following ones: + + -- base components (required) + + src/base/ftsystem.c + src/base/ftinit.c + src/base/ftdebug.c + src/base/ftbase.c + src/base/ftglyph.c + src/base/ftbbox.c + src/base/ftmm.c + src/base/ftpfr.c -- optional, see <freetype/ftpfr.h> + src/base/ftbdf.c -- optional, see <freetype/ftbdf.h> + src/base/ftwinfnt.c -- optional, see <freetype/ftwinfnt.h> + + src/base/ftmac.c -- only on the Macintosh + + -- other components (optional) + + src/autohint/autohint.c -- auto hinting module + src/cache/ftcache.c -- cache sub-system (in beta) + src/sfnt/sfnt.c -- SFNT files support + (TrueType & OpenType) + src/cff/cff.c -- CFF/OpenType font driver + src/pfr/pfr.c -- PFR/TrueDoc font driver + src/bdf/bdf.c -- BDF font driver + src/pcf/pcf.c -- PCF font driver + src/psnames/psnames.c -- PostScript glyph names support + src/psaux/psaux.c -- PostScript Type 1 parsing + src/truetype/truetype.c -- TrueType font driver + src/type1/type1.c -- Type 1 font driver + src/cid/type1cid.c -- Type 1 CID-keyed font driver + src/winfonts/winfonts.c -- Windows FONT / FNT font driver + src/raster1/raster1.c -- monochrome rasterizer + src/smooth/smooth.c -- anti-aliasing rasterizer + + Notes: + + `truetype.c' needs `sfnt.c' and `psnames.c' + `type1.c' needs `psaux.c' and `psnames.c' + `type1cid.c' needs `psaux.c' and `psnames.c' + `cff.c' needs `sfnt.c', `psaux.c', and `psnames.c' + + + You are done. In case of problems, see the archives of the FreeType + development mailing list. + + +II. Support for flat-directory compilation +------------------------------------------ + + It is possible to put all FreeType 2 source files into a single + directory, with the *exception* of the `include' hierarchy. + + 1. Copy all files in current directory + + cp freetype2/src/base/*.[hc] . + cp freetype2/src/raster1/*.[hc] . + cp freetype2/src/smooth/*.[hc] . + etc. + + 2. Compile sources + + cc -c -Ifreetype2/include ftsystem.c + cc -c -Ifreetype2/include ftinit.c + cc -c -Ifreetype2/include ftdebug.c + cc -c -Ifreetype2/include ftbase.c + etc. + + You don't need to define the FT_FLAT_COMPILATION macro (as this was + required in previous releases of FreeType 2). + + +--- end of INSTALL.ANY --- diff --git a/nx-X11/extras/freetype2/docs/INSTALL.GNU b/nx-X11/extras/freetype2/docs/INSTALL.GNU new file mode 100644 index 000000000..4a56d6d6d --- /dev/null +++ b/nx-X11/extras/freetype2/docs/INSTALL.GNU @@ -0,0 +1,140 @@ +This document contains instructions how to build the FreeType library on +non-Unix systems with the help of GNU Make. Note that if you are +running Cygwin or MSys in Windows, you should follow the instructions in +the file INSTALL.UNX instead. + + + FreeType 2 includes a powerful and flexible build system that allows + you to easily compile it on a great variety of platforms from the + command line. To do so, just follow these simple instructions: + + 1. Install GNU Make + ------------------- + + Because GNU Make is the only Make tool supported to compile + FreeType 2, you should install it on your machine. + + The FreeType 2 build system relies on many features special to GNU + Make -- trying to build the library with any other Make tool will + *fail*. + + NEARLY ALL OTHER MAKE TOOLS WILL FAIL, INCLUDING "BSD MAKE", SO + REALLY INSTALL A RECENT VERSION OF GNU MAKE ON YOUR SYSTEM! + + Note that make++, a make tool written in Perl, supports enough + features of GNU make to compile FreeType. See + http://makepp.sourceforge.net for more information; you need version + 1.19 or newer, and you must pass option `--norc-substitution'. + + Make sure that you are invoking GNU Make from the command line, by + typing something like: + + make -v + + to display its version number. + + VERSION 3.78.1 OR NEWER IS NEEDED! + + + 2. Invoke 'make' + ---------------- + + Go to the root directory of FreeType 2, then simply invoke GNU Make + from the command line. This will launch the FreeType 2 host + platform detection routines. A summary will be displayed, for + example, on Win32: + + + ============================================================== + FreeType build system -- automatic system detection + + The following settings are used: + + platform win32 + compiler gcc + configuration directory ./builds/win32 + configuration rules ./builds/win32/w32-gcc.mk + + If this does not correspond to your system or settings please + remove the file 'config.mk' from this directory then read the + INSTALL file for help. + + Otherwise, simply type 'make' again to build the library. + ============================================================= + + + If the detected settings correspond to your platform and compiler, + skip to step 5. Note that if your platform is completely alien to + the build system, the detected platform will be 'ansi'. + + + 3. Configure the build system for a different compiler + ------------------------------------------------------ + + If the build system correctly detected your platform, but you want + to use a different compiler than the one specified in the summary + (for most platforms, gcc is the defaut compiler), invoke GNU Make + with + + make setup <compiler> + + Examples: + + to use Visual C++ on Win32, type: "make setup visualc" + to use Borland C++ on Win32, type "make setup bcc32" + to use Watcom C++ on Win32, type "make setup watcom" + to use Intel C++ on Win32, type "make setup intelc" + to use LCC-Win32 on Win32, type: "make setup lcc" + to use Watcom C++ on OS/2, type "make setup watcom" + to use VisualAge C++ on OS/2, type "make setup visualage" + + The <compiler> name to use is platform-dependent. The list of + available compilers for your system is available in the file + `builds/<system>/detect.mk' + + If you are satisfied by the new configuration summary, skip to + step 5. + + + 4. Configure the build system for an unknown platform/compiler + -------------------------------------------------------------- + + The auto-detection/setup phase of the build system copies a file to + the current directory under the name `config.mk'. + + For example, on OS/2+gcc, it would simply copy + `builds/os2/os2-gcc.mk' to `./config.mk'. + + If for some reason your platform isn't correctly detected, copy + manually the configuration sub-makefile to `./config.mk' and go to + step 5. + + Note that this file is a sub-Makefile used to specify Make variables + for compiler and linker invocation during the build. You can easily + create your own version from one of the existing configuration + files, then copy it to the current directory under the name + `./config.mk'. + + + 5. Build the library + -------------------- + + The auto-detection/setup phase should have copied a file in the + current directory, called `./config.mk'. This file contains + definitions of various Make variables used to invoke the compiler + and linker during the build. + + To launch the build, simply invoke GNU Make again: The top Makefile + will detect the configuration file and run the build with it. + + + Final note + + The build system builds a statically linked library of the font + engine in the "objs" directory. It does _not_ support the build of + DLLs on Windows and OS/2. If you need these, you have to either use + a IDE-specific project file, or follow the instructions in + "INSTALL.ANY" to create your own Makefiles. + + +--- end of INSTALL.GNU --- diff --git a/nx-X11/extras/freetype2/docs/INSTALL.UNX b/nx-X11/extras/freetype2/docs/INSTALL.UNX new file mode 100644 index 000000000..d5a45c042 --- /dev/null +++ b/nx-X11/extras/freetype2/docs/INSTALL.UNX @@ -0,0 +1,65 @@ +This document contains instructions on how to build the FreeType library +on Unix systems. This also works for emulations like Cygwin or MSys on +Win32: + + + 1. Ensure that you are using GNU Make + ------------------------------------- + + The FreeType build system _exclusively_ works with GNU Make. You + will not be able to compile the library with the instructions below + using any other alternative (including BSD Make). + + [Well, this is not really correct. Recently, a perl implementation + of make called `makepp' has appeared which can also build FreeType 2 + successfully on Unix platforms. See http://makepp.sourceforge.net + for more details; you need version 1.19 or newer, and you must pass + option `--norc-substitution'.] + + Trying to compile the library with a different Make tool will print + a message like: + + Sorry, GNU make is required to build FreeType2. + + and the build process will be aborted. If this happens, install GNU + Make on your system, and use the GNUMAKE environment variable to + name it. + + + 2. Build and install the library + -------------------------------- + + The following should work on all Unix systems where the `make' + command invokes GNU Make: + + ./configure [options] + make + make install (as root) + + The default installation path is "/usr/local". It can be changed + with the `--prefix=<path>' option. Example: + + ./configure --prefix=/usr + + When using a different command to invoke GNU Make, use the GNUMAKE + variable. For example, if `gmake' is the command to use on your + system, do something like: + + GNUMAKE=gmake ./configure [options] + gmake + gmake install (as root) + + If this still doesn't work, something's rotten on your system + (e.g. you are using a very old version of GNU Make). + + It is possible to compile FreeType in a different directory. + Assuming the FreeType source files in directory `/src/freetype' a + compilation in directory `foo' works as follows: + + cd foo + /src/freetype/configure [options] + make + make install + + +--- end of INSTALL.UNX -- diff --git a/nx-X11/extras/freetype2/docs/INSTALL.VMS b/nx-X11/extras/freetype2/docs/INSTALL.VMS new file mode 100644 index 000000000..4d9d64ca2 --- /dev/null +++ b/nx-X11/extras/freetype2/docs/INSTALL.VMS @@ -0,0 +1,36 @@ +How to build the freetype2 library on VMS +----------------------------------------- + +Just type one of the following depending on the type of external entries +you want: + + mms + +or + + mms/macro=("COMP_FLAGS=/name=(as_is,short)") + +The library is avalaible in the directory + + [.LIB] + +To compile applications using FreeType 2 you have to define the logical +FREETYPE pointing to the directory + + [.INCLUDE.FREETYPE] + +i.e., if the directory in which this INSTALL.VMS file is located is +$disk:[freetype] then define the logical with + + define freetype $disk:[freetype.include.freetype] + +This version has been tested with Compaq C V6.2-006 on OpenVMS Alpha +V7.2-1. + + + Any problems can be reported to + + Jouk Jansen <joukj@hrem.stm.tudelft.nl> + + +--- end of INSTALL.VMS --- diff --git a/nx-X11/extras/freetype2/docs/PATENTS b/nx-X11/extras/freetype2/docs/PATENTS new file mode 100644 index 000000000..717bb7d3f --- /dev/null +++ b/nx-X11/extras/freetype2/docs/PATENTS @@ -0,0 +1,27 @@ + + FreeType Patents Disclaimer + August 1999 + + + +WE HAVE DISCOVERED THAT APPLE OWNS SEVERAL PATENTS RELATED TO THE +RENDERING OF TRUETYPE FONTS. THIS COULD MEAN THAT THE FREE USE OF +FREETYPE MIGHT BE ILLEGAL IN THE USA, JAPAN, AND POSSIBLY OTHER +COUNTRIES, BE IT IN COMMERCIAL OR OPEN SOURCE PRODUCTS. + +FOR MORE DETAILS, WE STRONGLY ADVISE YOU TO GO TO THE FREETYPE +PATENTS PAGE AT THE FOLLOWING WEB ADDRESS: + + http://www.freetype.org/patents.html + +WE WILL NOT PLACE INFORMATION IN THIS FILE AS THE SITUATION IS STILL +UNDETERMINED FOR NOW. AT THE TIME THESE LINES ARE WRITTEN, WE HAVE +CONTACTED APPLE'S LEGAL DEPARTMENT AND ARE STILL WAITING FOR THEIR +ANSWER ON THE SUBJECT. + +PLEASE READ THE `INSTALL' FILE TO SEE HOW TO DISABLE THE ENGINE'S +BYTECODE INTERPRETER IN ORDER TO BUILD A PATENT-FREE ENGINE, AT THE +COST OF RENDERING QUALITY. + + +--- end of PATENTS --- diff --git a/nx-X11/extras/freetype2/docs/TODO b/nx-X11/extras/freetype2/docs/TODO new file mode 100644 index 000000000..592809acf --- /dev/null +++ b/nx-X11/extras/freetype2/docs/TODO @@ -0,0 +1,23 @@ +Here is a list of items that need to be addressed in FreeType 2; they are +not exactly bugs, but should be considered though: + +* Implement stem3/counter hints properly in the Postscript hinter. + +* Finalize the cache sub-system. It has been in beta far too long :-) + +* The automatic and Postscript hinters have been improved to increase + the quality of AA text, but Monochrome and LCD hinting still suck. We + need to do something about that. + +* Add CIDCMap support to the CID driver. + +* Add track kerning support to the Type1 and PFR driver and the API + (The degree of kerning, e.g. light, normal or tight, and + the glyph size has to be passed as parameter). + +* Add kerning (AFM file) support to the CID driver. + +* Possibly add support for reading PFM files. + + +--- end of TODO --- diff --git a/nx-X11/extras/freetype2/docs/TRUETYPE b/nx-X11/extras/freetype2/docs/TRUETYPE new file mode 100644 index 000000000..68ecf1971 --- /dev/null +++ b/nx-X11/extras/freetype2/docs/TRUETYPE @@ -0,0 +1,26 @@ +How to enable the TrueType native hinter if you need it +-------------------------------------------------------- + + The TrueType bytecode interpreter is disabled in all public releases + of the FreeType packages for patents reasons (see + http://www.freetype.org/patents.html for more details). + + However, many Linux distributions do enable the interpreter in the + FreeType packages (DEB/RPM/etc.) they produce for their platforms. If + you are using TrueType fonts on your system, you most probably want to + enable it manually by doing the following: + + - open the file "include/freetype/config/ftoption.h" + + - locate a line that says: + + #undef TT_CONFIG_OPTION_BYTECODE_INTERPRETER + + - change it to: + + #define TT_CONFIG_OPTION_BYTECODE_INTERPRETER + + These steps must be done _before_ compiling the library. + + +--- end of TRUETYPE --- diff --git a/nx-X11/extras/freetype2/docs/UPGRADE.UNX b/nx-X11/extras/freetype2/docs/UPGRADE.UNX new file mode 100644 index 000000000..0246b97c7 --- /dev/null +++ b/nx-X11/extras/freetype2/docs/UPGRADE.UNX @@ -0,0 +1,127 @@ + +SPECIAL NOTE FOR UNIX USERS +=========================== + + If you are installing this release of FreeType on a system that + already uses release 2.0.5 (or even an older version), you have to + perform a few special steps to ensure that everything goes well. + + + 1. Enable the TrueType bytecode hinter if you need it + ----------------------------------------------------- + + See the instructions in the file "TRUETYPE" of this directory. + + Note that FreeType supports TrueType fonts without the bytecode + interpreter through its auto-hinter, which now generates relatively + good results with most fonts. + + + 2. Determine the correct installation path + ------------------------------------------ + + By default, the configure script will install the library in + "/usr/local". However, many Unix distributions now install the + library in "/usr", since FreeType is becoming a critical system + component. + + If FreeType is already installed on your system, type + + freetype-config --prefix + + on the command line. This should return the installation path + (e.g., "/usr" or "/usr/local"). To avoid problems of parallel + FreeType versions, use this path for the --prefix option of the + configure script. + + Otherwise, simply use "/usr" (or whatever you think is adequate for + your installation). + + + 3. Ensure that you are using GNU Make + ------------------------------------- + + The FreeType build system _exclusively_ works with GNU Make (as an + exception you can use make++ which emulates GNU Make sufficiently; + see http://makepp.sourceforge.net). You will not be able to compile + the library with the instructions below using any other alternative + (including BSD Make). + + Trying to compile the library with a different Make tool will print + a message like: + + Sorry, GNU make is required to build FreeType2. + + and the build process will be aborted. If this happens, install GNU + Make on your system, and use the GNUMAKE environment variable to + name it. + + + 4. Build and install the library + -------------------------------- + + The following should work on all Unix systems where the `make' + command invokes GNU Make: + + ./configure --prefix=<yourprefix> + make + make install (as root) + + where "<yourprefix>" must be replaced by the prefix returned by the + "freetype-config" command. + + When using a different command to invoke GNU Make, use the GNUMAKE + variable. For example, if `gmake' is the command to use on your + system, do something like: + + GNUMAKE=gmake ./configure --prefix=<yourprefix> + gmake + gmake install (as root) + + + 5. Take care of XFree86 version 4 + --------------------------------- + + Certain recent Linux distributions will install _several_ versions + of FreeType on your system. For example, on a fresh Mandrake 8.1 + system, you can find the following files: + + /usr/lib/libfreetype.so which links to + /usr/lib/libfreetype.6.1.0.so + + and + + /usr/X11R6/lib/libfreetype.so which links to + /usr/X11R6/lib/libfreetype.6.0.so + + Note that these files correspond to two distinct versions of the + library! It seems that this surprising issue is due to the install + scripts of recent XFree86 servers (from 4.1.0) which install their + own (dated) version of the library in "/usr/X11R6/lib". + + In certain _rare_ cases you may experience minor problems if you + install this release of the library in "/usr" only, namely, that + certain applications will not benefit from the bug fixes and + rendering improvements you would expect. + + There are two good ways to deal with this situation: + + - Install the library _twice_, in "/usr" and in "/usr/X11R6" (you + have to do that each time you install a new FreeType release + though). + + - Change the link in /usr/X11R6/lib/libfreetype.so to point to + + /usr/lib/libfreetype.so, + + and get rid of + + /usr/X11R6/lib/libfreetype.6.0.so + + The FreeType Team is not responsible for this problem, so please + contact either the XFree86 development team or your Linux + distributor to help clear this issue in case the information given + here doesn't help. + + +---- end of UPGRADE.UNX --- diff --git a/nx-X11/extras/freetype2/docs/VERSION.DLL b/nx-X11/extras/freetype2/docs/VERSION.DLL new file mode 100644 index 000000000..9e27a57d2 --- /dev/null +++ b/nx-X11/extras/freetype2/docs/VERSION.DLL @@ -0,0 +1,110 @@ +Due to our use of "libtool" to generate and install the FreeType 2 +libraries on Unix systems, as well as other historical events, it is +generally very difficult to know precisely which release of the font +engine is installed on a given system. + +This file tries to explain why and to document ways to properly detect +FreeType on Unix. + + +1. Version & Release numbers +---------------------------- + +For each new public release of FreeType 2, there are generally *three* +distinct "version" numbers to consider: + + * The official FT2 release number, like 2.0.9, or 2.1.3. + + * The libtool (and Unix) specific version number, like "9.2.3". This + is what "freetype-config --version" will return. + + * The platform-specific shared object number, used for example when + the library is installed as "/usr/lib/libfreetype.so.6.3.2". + +The platform-specific number is, unsurprisingly, platform-specific and +varies with the operating system you are using (several variants of +Linux, FreeBSD, Solaris, etc.). You should thus _never_ use it, even +for simple tests. + +The libtool-specific number does not equal the release number but is +tied to it. + +The release number is available at *compile* time through the following +macros defined in FT_FREETYPE_H: + + - FREETYPE_MAJOR : major release number + - FREETYPE_MINOR : minor release number + - FREETYPE_PATCH : patch release number + +See below for a small autoconf fragment. + +The release number is also available at *runtime* through the +"FT_Library_Version" API. Unfortunately, this one wasn't available or +working correctly before the 2.1.3 official release. + + +2. History +---------- + +The following table gives, for each official release, the corresponding +libtool number, as well as the shared object number found on _most_ +systems, but not all of them: + + release libtool so + ------------------------------- + 2.1.9 9.7.3 6.3.7 + 2.1.8 9.6.3 6.3.6 + 2.1.7 9.5.3 6.3.5 + 2.1.6 9.5.3 6.3.5 + 2.1.5 9.4.3 6.3.4 + 2.1.4 9.3.3 6.3.3 + 2.1.3 9.2.3 6.3.2 + 2.1.2 9.1.3 6.3.1 + 2.1.1 9.0.3 ? + 2.1.0 8.0.2 ? + 2.0.9 9.0.3 ? + 2.0.8 8.0.2 ? + 2.0.4 7.0.1 ? + 2.0.1 6.1.0 ? + +The libtool numbers are a bit inconsistent due to the library's history: + + - 2.1.0 was created as a development branch from 2.0.8 (hence the same + libtool numbers). + + - 2.0.9 was a bug-fix release of the "stable" branch, and we + incorrectly increased its libtool number. + + - 2.1.4 is still in the "development" branch, however it is stable + enough to be the basis of an upcoming 2.2.0 release. + + +3. Autoconf Code Fragment +------------------------- + +Lars Clausen contributed the following autoconf fragment to detect which +version of FreeType is installed on a system. This one tests for a +version that is at least 2.0.9; you should change it to check against +other release numbers. + + + AC_MSG_CHECKING([whether FreeType version is 2.0.9 or higher]) + old_CPPFLAGS="$CPPFLAGS" + CPPFLAGS=`freetype-config --cflags` + AC_TRY_CPP([ + +#include <ft2build.h> +#include FT_FREETYPE_H +#if (FREETYPE_MAJOR*1000 + FREETYPE_MINOR)*1000 + FREETYPE_PATCH < 2000009 +#error Freetype version too low. +#endif + ], + [AC_MSG_RESULT(yes) + FREETYPE_LIBS=`freetype-config --libs` + AC_SUBST(FREETYPE_LIBS) + AC_DEFINE(HAVE_FREETYPE,1,[Define if you have the FreeType2 library]) + CPPFLAGS="$old_CPPFLAGS"], + [AC_MSG_ERROR([Need FreeType library version 2.0.9 or higher])]) + + +--- end of VERSION.DLL --- diff --git a/nx-X11/extras/freetype2/docs/formats.txt b/nx-X11/extras/freetype2/docs/formats.txt new file mode 100644 index 000000000..b11f6c409 --- /dev/null +++ b/nx-X11/extras/freetype2/docs/formats.txt @@ -0,0 +1,139 @@ +This file contains a list of various font formats. It gives the +reference document and whether it is supported in FreeType 2. + + + file type: + The only special case is `MAC'; on older Mac OS versions, a `file' + is stored as a data and a resource fork, this is, within two + separate data chunks. In all other cases, the font data is stored + in a single file. + + wrapper format: + The format used to represent the font data. In the table below it + is used only if the font format differs. Possible values are + `SFNT' (binary), `PS' (a text header, followed by binary or text + data), and `LZW' (compressed with either `gzip' or `compress'). + + font format: + How the font is to be accessed, possibly after converting the file + type and wrapper format into a generic form. Bitmap formats are + `BDF', `PCF', and one form of `WINFNT'; all others are vector + formats. + + font type: + Sub-formats of the font format. `SBIT' and `MACSBIT' are bitmap + formats, `MM' and `VAR' support optical axes. + + glyph access: + If not specified, the glyph access is `standard' to the font + format. Values are `CID' for CID-keyed fonts, `SYNTHETIC' for + fonts which are modified versions of other fonts by means of a + transformation matrix, `COLLECTION' for collecting multiple fonts + (sharing most of the data) into a single file, and `TYPE_0' for PS + fonts which are to be accessed in a tree-like structure. + + FreeType driver: + The module in the FreeType library which handles the specific font + format. A missing entry means that FreeType doesn't support the + font format (yet). + + +Please send additions and/or corrections to wl@gnu.org or to the +FreeType developer's list at devel@freetype (for subscribers only). If +you can provide a font example for a format which isn't supported yet +please send a mail too. + + +file wrapper font font glyph FreeType reference +type format format type access driver documents +---------------------------------------------------------------------------- + +--- --- BDF --- --- bdf 5005.BDF_Spec.pdf, X11 + + +--- SFNT PS TYPE_1 --- --- Type 1 GX Font Format + (for the Mac) +MAC SFNT PS TYPE_1 --- --- Type 1 GX Font Format + (for the Mac) +--- SFNT PS TYPE_1 CID --- 5180.sfnt.pdf (for the Mac) +MAC SFNT PS TYPE_1 CID --- 5180.sfnt.pdf (for the Mac) +--- SFNT PS CFF --- cff OT spec, 5176.CFF.pdf + (`OTTO' format) +MAC SFNT PS CFF --- cff OT spec, 5176.CFF.pdf + (`OTTO' format) +--- SFNT PS CFF CID cff OT spec, 5176.CFF.pdf +MAC SFNT PS CFF CID cff OT spec, 5176.CFF.pdf +--- SFNT PS CFF SYNTHETIC --- OT spec, 5176.CFF.pdf +MAC SFNT PS CFF SYNTHETIC --- OT spec, 5176.CFF.pdf +--- SFNT TT SBIT --- --- XFree86? (bitmaps only; + `head' table) +--- SFNT TT MACSBIT --- sfnt OT spec (for the Mac; + bitmaps only; `bhed' table) +MAC SFNT TT MACSBIT --- sfnt OT spec (for the Mac; + bitmaps only; `bhed' table) +--- SFNT TT --- --- truetype OT spec (`normal' TT font) +MAC SFNT TT --- --- truetype OT spec (`normal' TT font) +MAC SFNT TT VAR --- truetype GX spec (`?var' tables) +--- SFNT TT --- COLLECTION truetype OT spec (this can't be CFF) +MAC SFNT TT --- COLLECTION truetype OT spec (this can't be CFF) + + +--- --- PS TYPE_1 --- type1 T1_SPEC.pdf + (`normal' Type 1 font) +MAC --- PS TYPE_1 --- type1 T1_SPEC.pdf + (`normal' Type 1 font) +--- --- PS TYPE_1 CID cid PLRM.pdf (CID Font Type 0; + Type 9 font) +--- --- PS MM --- type1 5015.Type1_Supp.pdf + (Multiple Masters) +--- --- PS CFF --- cff 5176.CFF.pdf (`pure' CFF) +--- --- PS CFF CID cff 5176.CFF.pdf (`pure' CFF) +--- --- PS CFF SYNTHETIC --- 5176.CFF.pdf (`pure' CFF) +--- PS PS CFF --- --- PLRM.pdf (Type 2) [1] +--- PS PS CFF CID --- PLRM.pdf (Type 2) [1] +--- PS PS CFF SYNTHETIC --- PLRM.pdf (Type 2) [1] +--- --- PS --- TYPE_0 --- PLRM.pdf +--- --- PS TYPE_3 --- --- PLRM.pdf (never supported) +--- --- PS TYPE_3 CID --- PLRM.pdf (CID Font Type 1; + Type 10 font; never supported) +--- PS PS TYPE_14 --- --- PLRM.pdf (Chameleon font; + Type 14 font; never supported?) +--- --- PS TYPE_32 CID --- PLRM.pdf (CID Font Type 4; + Type 32 font; never supported?) +--- PS TT --- --- type42 5012.Type42_Spec.pdf + (Type 42 font) +--- PS TT --- CID --- PLRM.pdf (CID Font Type 2; + Type 11 font) + + +--- ? ? CEF ? cff ? + + +--- --- PCF --- --- pcf X11 +--- LZW PCF --- --- pcf X11 + + +--- --- PFR PFR0 --- pfr [2] +--- --- PFR PFR1 --- --- (undocumented, proprietary; + probably never supported) + + +--- --- WINFNT --- --- winfonts MS Windows 3 Developer's Notes +--- --- WINFNT VECTOR --- --- MS Windows 3 Developer's Notes + + +[1] Support should be rather simple since this is identical to `CFF' + but in a PS wrapper. + +[2] Official PFR specification: + + http://www.bitstream.com/categories/developer/truedoc/pfrspec.html + http://www.bitstream.com/categories/developer/truedoc/pfrspec1.2.pdf + + The syntax of the auxiliary data is not defined there, but is partially + defined in MHP 1.0.3 (also called ETSI TS 101812 V1.3.1) section 7.4. + + http://www.etsi.org/ + http://webapp.etsi.org/workprogram/Report_WorkItem.asp?WKI_ID=18799 + + (free registration required). diff --git a/nx-X11/extras/freetype2/docs/license.txt b/nx-X11/extras/freetype2/docs/license.txt new file mode 100644 index 000000000..876cc4b93 --- /dev/null +++ b/nx-X11/extras/freetype2/docs/license.txt @@ -0,0 +1,28 @@ + +The FreeType 2 font engine is copyrighted work and cannot be used +legally without a software license. In order to make this project +usable to a vast majority of developers, we distribute it under two +mutually exclusive open-source licenses. + +This means that *you* must choose *one* of the two licenses described +below, then obey all its terms and conditions when using FreeType 2 in +any of your projects or products. + + - The FreeType License, found in the file `FTL.TXT', which is similar + to the original BSD license *with* an advertising clause that forces + you to explicitly cite the FreeType project in your product's + documentation. All details are in the license file. This license + is suited to products which don't use the GNU General Public + License. + + - The GNU General Public License version 2, found in `GPL.TXT' (any + later version can be used also), for programs which already use the + GPL. Note that the FTL is incompatible with the GPL due to its + advertisement clause. + +The contributed PCF driver comes with a license similar to that of the X +Window System. It is compatible to the above two licenses (see file +src/pcf/readme). + + +--- end of licence.txt --- diff --git a/nx-X11/extras/freetype2/docs/modules.txt b/nx-X11/extras/freetype2/docs/modules.txt new file mode 100644 index 000000000..04f4d120a --- /dev/null +++ b/nx-X11/extras/freetype2/docs/modules.txt @@ -0,0 +1,14 @@ +This file shows the interdependencies of various FreeType modules. + +Note that the use of `psnames' can be controlled in ftconfig.h +(FT_CONFIG_OPTION_POSTSCRIPT_NAMES). + + module dependency + --------------------------------------- + cff sfnt, pshinter, psnames + cid psaux, pshinter, psnames + truetype sfnt + type1 psaux, pshinter, psnames + type42 truetype + psaux psnames + sfnt psnames diff --git a/nx-X11/extras/freetype2/docs/raster.txt b/nx-X11/extras/freetype2/docs/raster.txt new file mode 100644 index 000000000..078c51aa1 --- /dev/null +++ b/nx-X11/extras/freetype2/docs/raster.txt @@ -0,0 +1,624 @@ + + How FreeType's rasterizer work + + by David Turner + + Revised 2003-Dec-08 + + +This file is an attempt to explain the internals of the FreeType +rasterizer. The rasterizer is of quite general purpose and could +easily be integrated into other programs. + + + I. Introduction + + II. Rendering Technology + 1. Requirements + 2. Profiles and Spans + a. Sweeping the Shape + b. Decomposing Outlines into Profiles + c. The Render Pool + d. Computing Profiles Extents + e. Computing Profiles Coordinates + f. Sweeping and Sorting the Spans + + +I. Introduction +=============== + + A rasterizer is a library in charge of converting a vectorial + representation of a shape into a bitmap. The FreeType rasterizer + has been originally developed to render the glyphs found in + TrueType files, made up of segments and second-order Béziers. + Meanwhile it has been extended to render third-order Bézier curves + also. This document is an explanation of its design and + implementation. + + While these explanations start from the basics, a knowledge of + common rasterization techniques is assumed. + + +II. Rendering Technology +======================== + +1. Requirements +--------------- + + We assume that all scaling, rotating, hinting, etc., has been + already done. The glyph is thus described by a list of points in + the device space. + + - All point coordinates are in the 26.6 fixed float format. The + used orientation is: + + + ^ y + | reference orientation + | + *----> x + 0 + + + `26.6' means that 26 bits are used for the integer part of a + value and 6 bits are used for the fractional part. + Consequently, the `distance' between two neighbouring pixels is + 64 `units' (1 unit = 1/64th of a pixel). + + Note that, for the rasterizer, pixel centers are located at + integer coordinates. The TrueType bytecode interpreter, + however, assumes that the lower left edge of a pixel (which is + taken to be a square with a length of 1 unit) has integer + coordinates. + + + ^ y ^ y + | | + | (1,1) | (0.5,0.5) + +-----------+ +-----+-----+ + | | | | | + | | | | | + | | | o-----+-----> x + | | | (0,0) | + | | | | + o-----------+-----> x +-----------+ + (0,0) (-0.5,-0.5) + + TrueType bytecode interpreter FreeType rasterizer + + + A pixel line in the target bitmap is called a `scanline'. + + - A glyph is usually made of several contours, also called + `outlines'. A contour is simply a closed curve that delimits an + outer or inner region of the glyph. It is described by a series + of successive points of the points table. + + Each point of the glyph has an associated flag that indicates + whether it is `on' or `off' the curve. Two successive `on' + points indicate a line segment joining the two points. + + One `off' point amidst two `on' points indicates a second-degree + (conic) Bézier parametric arc, defined by these three points + (the `off' point being the control point, and the `on' ones the + start and end points). Similarly, a third-degree (cubic) Bézier + curve is described by four points (two `off' control points + between two `on' points). + + Finally, for second-order curves only, two successive `off' + points forces the rasterizer to create, during rendering, an + `on' point amidst them, at their exact middle. This greatly + facilitates the definition of successive Bézier arcs. + + The parametric form of a second-order Bézier curve is: + + P(t) = (1-t)^2*P1 + 2*t*(1-t)*P2 + t^2*P3 + + (P1 and P3 are the end points, P2 the control point.) + + The parametric form of a third-order Bézier curve is: + + P(t) = (1-t)^3*P1 + 3*t*(1-t)^2*P2 + 3*t^2*(1-t)*P3 + t^3*P4 + + (P1 and P4 are the end points, P2 and P3 the control points.) + + For both formulae, t is a real number in the range [0..1]. + + Note that the rasterizer does not use these formulae directly. + They exhibit, however, one very useful property of Bézier arcs: + Each point of the curve is a weighted average of the control + points. + + As all weights are positive and always sum up to 1, whatever the + value of t, each arc point lies within the triangle (polygon) + defined by the arc's three (four) control points. + + In the following, only second-order curves are discussed since + rasterization of third-order curves is completely identical. + + Here some samples for second-order curves. + + + * # on curve + * off curve + __---__ + #-__ _-- -_ + --__ _- - + --__ # \ + --__ # + -# + Two `on' points + Two `on' points and one `off' point + between them + + * + # __ Two `on' points with two `off' + \ - - points between them. The point + \ / \ marked `0' is the middle of the + - 0 \ `off' points, and is a `virtual + -_ _- # on' point where the curve passes. + -- It does not appear in the point + * list. + + +2. Profiles and Spans +--------------------- + + The following is a basic explanation of the _kind_ of computations + made by the rasterizer to build a bitmap from a vector + representation. Note that the actual implementation is slightly + different, due to performance tuning and other factors. + + However, the following ideas remain in the same category, and are + more convenient to understand. + + + a. Sweeping the Shape + + The best way to fill a shape is to decompose it into a number of + simple horizontal segments, then turn them on in the target + bitmap. These segments are called `spans'. + + __---__ + _-- -_ + _- - + - \ + / \ + / \ + | \ + + __---__ Example: filling a shape + _----------_ with spans. + _-------------- + ----------------\ + /-----------------\ This is typically done from the top + / \ to the bottom of the shape, in a + | | \ movement called a `sweep'. + V + + __---__ + _----------_ + _-------------- + ----------------\ + /-----------------\ + /-------------------\ + |---------------------\ + + + In order to draw a span, the rasterizer must compute its + coordinates, which are simply the x coordinates of the shape's + contours, taken on the y scanlines. + + + /---/ |---| Note that there are usually + /---/ |---| several spans per scanline. + | /---/ |---| + | /---/_______|---| When rendering this shape to the + V /----------------| current scanline y, we must + /-----------------| compute the x values of the + a /----| |---| points a, b, c, and d. + - - - * * - - - - * * - - y - + / / b c| |d + + + /---/ |---| + /---/ |---| And then turn on the spans a-b + /---/ |---| and c-d. + /---/_______|---| + /----------------| + /-----------------| + a /----| |---| + - - - ####### - - - - ##### - - y - + / / b c| |d + + + b. Decomposing Outlines into Profiles + + For each scanline during the sweep, we need the following + information: + + o The number of spans on the current scanline, given by the + number of shape points intersecting the scanline (these are + the points a, b, c, and d in the above example). + + o The x coordinates of these points. + + x coordinates are computed before the sweep, in a phase called + `decomposition' which converts the glyph into *profiles*. + + Put it simply, a `profile' is a contour's portion that can only + be either ascending or descending, i.e., it is monotonic in the + vertical direction (we also say y-monotonic). There is no such + thing as a horizontal profile, as we shall see. + + Here are a few examples: + + + this square + 1 2 + ---->---- is made of two + | | | | + | | profiles | | + ^ v ^ + v + | | | | + | | | | + ----<---- + + up down + + + this triangle + + P2 1 2 + + |\ is made of two | \ + ^ | \ \ | \ + | | \ \ profiles | \ | + | | \ v ^ | \ | + | \ | | + \ v + | \ | | \ + P1 ---___ \ ---___ \ + ---_\ ---_ \ + <--__ P3 up down + + + + A more general contour can be made of more than two profiles: + + __ ^ + / | / ___ / | + / | / | / | / | + | | / / => | v / / + | | | | | | ^ | + ^ | |___| | | ^ + | + | + v + | | | v | | + | | | up | + |___________| | down | + + <-- up down + + + Successive profiles are always joined by horizontal segments + that are not part of the profiles themselves. + + For the rasterizer, a profile is simply an *array* that + associates one horizontal *pixel* coordinate to each bitmap + *scanline* crossed by the contour's section containing the + profile. Note that profiles are *oriented* up or down along the + glyph's original flow orientation. + + In other graphics libraries, profiles are also called `edges' or + `edgelists'. + + + c. The Render Pool + + FreeType has been designed to be able to run well on _very_ + light systems, including embedded systems with very few memory. + + A render pool will be allocated once; the rasterizer uses this + pool for all its needs by managing this memory directly in it. + The algorithms that are used for profile computation make it + possible to use the pool as a simple growing heap. This means + that this memory management is actually quite easy and faster + than any kind of malloc()/free() combination. + + Moreover, we'll see later that the rasterizer is able, when + dealing with profiles too large and numerous to lie all at once + in the render pool, to immediately decompose recursively the + rendering process into independent sub-tasks, each taking less + memory to be performed (see `sub-banding' below). + + The render pool doesn't need to be large. A 4KByte pool is + enough for nearly all renditions, though nearly 100% slower than + a more confortable 16KByte or 32KByte pool (that was tested with + complex glyphs at sizes over 500 pixels). + + + d. Computing Profiles Extents + + Remember that a profile is an array, associating a _scanline_ to + the x pixel coordinate of its intersection with a contour. + + Though it's not exactly how the FreeType rasterizer works, it is + convenient to think that we need a profile's height before + allocating it in the pool and computing its coordinates. + + The profile's height is the number of scanlines crossed by the + y-monotonic section of a contour. We thus need to compute these + sections from the vectorial description. In order to do that, + we are obliged to compute all (local and global) y extrema of + the glyph (minima and maxima). + + + P2 For instance, this triangle has only + two y-extrema, which are simply + |\ + | \ P2.y as a vertical maximum + | \ P3.y as a vertical minimum + | \ + | \ P1.y is not a vertical extremum (though + | \ it is a horizontal minimum, which we + P1 ---___ \ don't need). + ---_\ + P3 + + + Note that the extrema are expressed in pixel units, not in + scanlines. The triangle's height is certainly (P3.y-P2.y+1) + pixel units, but its profiles' heights are computed in + scanlines. The exact conversion is simple: + + - min scanline = FLOOR ( min y ) + - max scanline = CEILING( max y ) + + A problem arises with Bézier Arcs. While a segment is always + necessarily y-monotonic (i.e., flat, ascending, or descending), + which makes extrema computations easy, the ascent of an arc can + vary between its control points. + + + P2 + * + # on curve + * off curve + __-x--_ + _-- -_ + P1 _- - A non y-monotonic Bézier arc. + # \ + - The arc goes from P1 to P3. + \ + \ P3 + # + + + We first need to be able to easily detect non-monotonic arcs, + according to their control points. I will state here, without + proof, that the monotony condition can be expressed as: + + P1.y <= P2.y <= P3.y for an ever-ascending arc + + P1.y >= P2.y >= P3.y for an ever-descending arc + + with the special case of + + P1.y = P2.y = P3.y where the arc is said to be `flat'. + + As you can see, these conditions can be very easily tested. + They are, however, extremely important, as any arc that does not + satisfy them necessarily contains an extremum. + + Note also that a monotonic arc can contain an extremum too, + which is then one of its `on' points: + + + P1 P2 + #---__ * P1P2P3 is ever-descending, but P1 + -_ is an y-extremum. + - + ---_ \ + -> \ + \ P3 + # + + + Let's go back to our previous example: + + + P2 + * + # on curve + * off curve + __-x--_ + _-- -_ + P1 _- - A non-y-monotonic Bézier arc. + # \ + - Here we have + \ P2.y >= P1.y && + \ P3 P2.y >= P3.y (!) + # + + + We need to compute the vertical maximum of this arc to be able + to compute a profile's height (the point marked by an `x'). The + arc's equation indicates that a direct computation is possible, + but we rely on a different technique, which use will become + apparent soon. + + Bézier arcs have the special property of being very easily + decomposed into two sub-arcs, which are themselves Bézier arcs. + Moreover, it is easy to prove that there is at most one vertical + extremum on each Bézier arc (for second-degree curves; similar + conditions can be found for third-order arcs). + + For instance, the following arc P1P2P3 can be decomposed into + two sub-arcs Q1Q2Q3 and R1R2R3: + + + P2 + * + # on curve + * off curve + + + original Bézier arc P1P2P3. + __---__ + _-- --_ + _- -_ + - - + / \ + / \ + # # + P1 P3 + + + + P2 + * + + + + Q3 Decomposed into two subarcs + Q2 R2 Q1Q2Q3 and R1R2R3 + * __-#-__ * + _-- --_ + _- R1 -_ Q1 = P1 R3 = P3 + - - Q2 = (P1+P2)/2 R2 = (P2+P3)/2 + / \ + / \ Q3 = R1 = (Q2+R2)/2 + # # + Q1 R3 Note that Q2, R2, and Q3=R1 + are on a single line which is + tangent to the curve. + + + We have then decomposed a non-y-monotonic Bézier curve into two + smaller sub-arcs. Note that in the above drawing, both sub-arcs + are monotonic, and that the extremum is then Q3=R1. However, in + a more general case, only one sub-arc is guaranteed to be + monotonic. Getting back to our former example: + + + Q2 + * + + __-x--_ R1 + _-- #_ + Q1 _- Q3 - R2 + # \ * + - + \ + \ R3 + # + + + Here, we see that, though Q1Q2Q3 is still non-monotonic, R1R2R3 + is ever descending: We thus know that it doesn't contain the + extremum. We can then re-subdivide Q1Q2Q3 into two sub-arcs and + go on recursively, stopping when we encounter two monotonic + subarcs, or when the subarcs become simply too small. + + We will finally find the vertical extremum. Note that the + iterative process of finding an extremum is called `flattening'. + + + e. Computing Profiles Coordinates + + Once we have the height of each profile, we are able to allocate + it in the render pool. The next task is to compute coordinates + for each scanline. + + In the case of segments, the computation is straightforward, + using the Euclidian algorithm (also known as Bresenham). + However, for Bézier arcs, the job is a little more complicated. + + We assume that all Béziers that are part of a profile are the + result of flattening the curve, which means that they are all + y-monotonic (ascending or descending, and never flat). We now + have to compute the intersections of arcs with the profile's + scanlines. One way is to use a similar scheme to flattening + called `stepping'. + + + Consider this arc, going from P1 to + --------------------- P3. Suppose that we need to + compute its intersections with the + drawn scanlines. As already + --------------------- mentioned this can be done + directly, but the involed algorithm + * P2 _---# P3 is far too slow. + ------------- _-- -- + _- + _/ Instead, it is still possible to + ---------/----------- use the decomposition property in + / the same recursive way, i.e., + | subdivide the arc into subarcs + ------|-------------- until these get too small to cross + | more than one scanline! + | + -----|--------------- This is very easily done using a + | rasterizer-managed stack of + | subarcs. + # P1 + + + f. Sweeping and Sorting the Spans + + Once all our profiles have been computed, we begin the sweep to + build (and fill) the spans. + + As both the TrueType and Type 1 specifications use the winding + fill rule (but with opposite directions), we place, on each + scanline, the present profiles in two separate lists. + + One list, called the `left' one, only contains ascending + profiles, while the other `right' list contains the descending + profiles. + + As each glyph is made of closed curves, a simple geometric + property ensures that the two lists contain the same number of + elements. + + Creating spans is thus straightforward: + + 1. We sort each list in increasing horizontal order. + + 2. We pair each value of the left list with its corresponding + value in the right list. + + + / / | | For example, we have here + / / | | four profiles. Two of + >/ / | | | them are ascending (1 & + 1// / ^ | | | 2 3), while the two others + // // 3| | | v are descending (2 & 4). + / //4 | | | On the given scanline, + a / /< | | the left list is (1,3), + - - - *-----* - - - - *---* - - y - and the right one is + / / b c| |d (4,2) (sorted). + + There are then two spans, joining + 1 to 4 (i.e. a-b) and 3 to 2 + (i.e. c-d)! + + + Sorting doesn't necessarily take much time, as in 99 cases out + of 100, the lists' order is kept from one scanline to the next. + We can thus implement it with two simple singly-linked lists, + sorted by a classic bubble-sort, which takes a minimum amount of + time when the lists are already sorted. + + A previous version of the rasterizer used more elaborate + structures, like arrays to perform `faster' sorting. It turned + out that this old scheme is not faster than the one described + above. + + Once the spans have been `created', we can simply draw them in + the target bitmap. + + +--- end of raster.txt --- + +Local Variables: +coding: latin-1 +End: diff --git a/nx-X11/extras/freetype2/docs/reference/.cvsignore b/nx-X11/extras/freetype2/docs/reference/.cvsignore new file mode 100644 index 000000000..2d19fc766 --- /dev/null +++ b/nx-X11/extras/freetype2/docs/reference/.cvsignore @@ -0,0 +1 @@ +*.html diff --git a/nx-X11/extras/freetype2/docs/reference/README b/nx-X11/extras/freetype2/docs/reference/README new file mode 100644 index 000000000..7c3467b53 --- /dev/null +++ b/nx-X11/extras/freetype2/docs/reference/README @@ -0,0 +1,2 @@ +After saying `make refdoc' this directory contains the FreeType API +reference. You need python to make this target. diff --git a/nx-X11/extras/freetype2/docs/release b/nx-X11/extras/freetype2/docs/release new file mode 100644 index 000000000..7cf37b849 --- /dev/null +++ b/nx-X11/extras/freetype2/docs/release @@ -0,0 +1,32 @@ +How to prepare a new release +---------------------------- + +. include/freetype/freetype.h: Update FREETYPE_MAJOR, FREETYPE_MINOR, and + FREETYPE_PATCH. + +. builds/unix/configure.ac (version_info): Update according to the libtool + rules, then regenerate the configure script. + +. builds/freetype.mk (refdoc): Update the `--title' option. + +. docs/CHANGES: Document differences to last release. + +. README: Update. + +. docs/VERSION.DLL: Document changed `version_info'. + +. ChangeLog: Announce new release. + +. Call `make refdoc' to update HTML reference. Copy it to + freetype2/docs/reference in the `www' CVS module and update the CVS. + Then call `update-www' in ~/cvs/scripts on www.freetype.org to + update and distribute everything to sourceforge. + +. Tag the CVS (freetype, ft2demos, www/freetype2/docs). + +. Update `make-release' and `make-current' in ~/cvs/scripts/ on + www.freetype.org, then call them. + +. Create an md5 checksum file (with md5sum). + +. Announce new release on announce@freetype.org and to relevant newsgroups. |