diff options
| author | Mike Gabriel <mike.gabriel@das-netzwerkteam.de> | 2015-02-02 15:02:49 +0100 |
|---|---|---|
| committer | Mike Gabriel <mike.gabriel@das-netzwerkteam.de> | 2015-02-02 15:02:49 +0100 |
| commit | b16b9e4656e7199c2aec74a4c8ebc7a875d3ba73 (patch) | |
| tree | 4361edef0d42d5bf5ac984ef72b4fac35426eae7 /nx-X11/extras/freetype2/docs | |
| parent | 0d5a83e986f39982c0924652a3662e60b1f23162 (diff) | |
| download | nx-libs-b16b9e4656e7199c2aec74a4c8ebc7a875d3ba73.tar.gz nx-libs-b16b9e4656e7199c2aec74a4c8ebc7a875d3ba73.tar.bz2 nx-libs-b16b9e4656e7199c2aec74a4c8ebc7a875d3ba73.zip | |
massive reduction of unneeded files
Diffstat (limited to 'nx-X11/extras/freetype2/docs')
22 files changed, 0 insertions, 4858 deletions
diff --git a/nx-X11/extras/freetype2/docs/CHANGES b/nx-X11/extras/freetype2/docs/CHANGES deleted file mode 100644 index fdb9ce33d..000000000 --- a/nx-X11/extras/freetype2/docs/CHANGES +++ /dev/null @@ -1,2477 +0,0 @@ - -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 deleted file mode 100644 index 8709b3dec..000000000 --- a/nx-X11/extras/freetype2/docs/CUSTOMIZE +++ /dev/null @@ -1,125 +0,0 @@ -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 deleted file mode 100644 index c85ef3cb1..000000000 --- a/nx-X11/extras/freetype2/docs/DEBUG +++ /dev/null @@ -1,183 +0,0 @@ -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 deleted file mode 100644 index 096730273..000000000 --- a/nx-X11/extras/freetype2/docs/FTL.txt +++ /dev/null @@ -1,174 +0,0 @@ - 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 deleted file mode 100644 index e8a612e5c..000000000 --- a/nx-X11/extras/freetype2/docs/GPL.txt +++ /dev/null @@ -1,339 +0,0 @@ - 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 deleted file mode 100644 index 8fb665759..000000000 --- a/nx-X11/extras/freetype2/docs/INSTALL +++ /dev/null @@ -1,67 +0,0 @@ - -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 deleted file mode 100644 index af3f6e7a3..000000000 --- a/nx-X11/extras/freetype2/docs/INSTALL.ANY +++ /dev/null @@ -1,99 +0,0 @@ -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 deleted file mode 100644 index 4a56d6d6d..000000000 --- a/nx-X11/extras/freetype2/docs/INSTALL.GNU +++ /dev/null @@ -1,140 +0,0 @@ -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 deleted file mode 100644 index d5a45c042..000000000 --- a/nx-X11/extras/freetype2/docs/INSTALL.UNX +++ /dev/null @@ -1,65 +0,0 @@ -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 deleted file mode 100644 index 4d9d64ca2..000000000 --- a/nx-X11/extras/freetype2/docs/INSTALL.VMS +++ /dev/null @@ -1,36 +0,0 @@ -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 deleted file mode 100644 index 717bb7d3f..000000000 --- a/nx-X11/extras/freetype2/docs/PATENTS +++ /dev/null @@ -1,27 +0,0 @@ - - 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 deleted file mode 100644 index 592809acf..000000000 --- a/nx-X11/extras/freetype2/docs/TODO +++ /dev/null @@ -1,23 +0,0 @@ -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 deleted file mode 100644 index 68ecf1971..000000000 --- a/nx-X11/extras/freetype2/docs/TRUETYPE +++ /dev/null @@ -1,26 +0,0 @@ -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 deleted file mode 100644 index 0246b97c7..000000000 --- a/nx-X11/extras/freetype2/docs/UPGRADE.UNX +++ /dev/null @@ -1,127 +0,0 @@ - -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 deleted file mode 100644 index 9e27a57d2..000000000 --- a/nx-X11/extras/freetype2/docs/VERSION.DLL +++ /dev/null @@ -1,110 +0,0 @@ -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 deleted file mode 100644 index b11f6c409..000000000 --- a/nx-X11/extras/freetype2/docs/formats.txt +++ /dev/null @@ -1,139 +0,0 @@ -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 deleted file mode 100644 index 876cc4b93..000000000 --- a/nx-X11/extras/freetype2/docs/license.txt +++ /dev/null @@ -1,28 +0,0 @@ - -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 deleted file mode 100644 index 04f4d120a..000000000 --- a/nx-X11/extras/freetype2/docs/modules.txt +++ /dev/null @@ -1,14 +0,0 @@ -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 deleted file mode 100644 index 078c51aa1..000000000 --- a/nx-X11/extras/freetype2/docs/raster.txt +++ /dev/null @@ -1,624 +0,0 @@ - - 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 deleted file mode 100644 index 2d19fc766..000000000 --- a/nx-X11/extras/freetype2/docs/reference/.cvsignore +++ /dev/null @@ -1 +0,0 @@ -*.html diff --git a/nx-X11/extras/freetype2/docs/reference/README b/nx-X11/extras/freetype2/docs/reference/README deleted file mode 100644 index 7c3467b53..000000000 --- a/nx-X11/extras/freetype2/docs/reference/README +++ /dev/null @@ -1,2 +0,0 @@ -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 deleted file mode 100644 index 7cf37b849..000000000 --- a/nx-X11/extras/freetype2/docs/release +++ /dev/null @@ -1,32 +0,0 @@ -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. |