======================================================================== * freetype README ======================================================================== FreeType 2.4.11 =============== Please read the docs/CHANGES file, it contains IMPORTANT INFORMATION. Read the files `docs/INSTALL' for installation instructions. See the file `docs/LICENSE.TXT' for the available licenses. Note that we use ranges (`2008-2010') for copyright years also instead of listing individual years (`2008, 2009, 2010'). The FreeType 2 API reference is located in `docs/reference'; use the file `ft2-doc.html' as the top entry point. Additional documentation is available as a separate package from our sites. Go to http://download.savannah.gnu.org/releases/freetype/ and download one of the following files. freetype-doc-2.4.11.tar.bz2 freetype-doc-2.4.11.tar.gz ftdoc2411.zip Bugs ==== Please report bugs by e-mail to `freetype-devel@nongnu.org'. Don't forget to send a detailed explanation of the problem -- there is nothing worse than receiving a terse message that only says `it doesn't work'. Alternatively, you may submit a bug report at https://savannah.nongnu.org/bugs/?group=freetype Enjoy! The FreeType Team ---------------------------------------------------------------------- Copyright 2006-2012 by David Turner, Robert Wilhelm, and Werner Lemberg. This file is part of the FreeType project, and may only be used, modified, and distributed under the terms of the FreeType project license, LICENSE.TXT. By continuing to use, modify, or distribute this file you indicate that you have read the license and understand and accept it fully. --- end of README --- ======================================================================== * freetype README.git ======================================================================== The git archive doesn't contain pre-built configuration scripts for UNIXish platforms. To generate them say sh autogen.sh which in turn depends on the following packages: automake (1.10.1) libtool (2.2.4) autoconf (2.62) The versions given in parentheses are known to work. Newer versions should work too, of course. Note that autogen.sh also sets up proper file permissions for the `configure' and auxiliary scripts. The autogen.sh script now checks the version of above three packages whether they match the numbers above. Otherwise it will complain and suggest either upgrading or using an environment variable to point to a more recent version of the required tool(s). Note that `aclocal' is provided by the `automake' package on Linux, and that `libtoolize' is called `glibtoolize' on Darwin (OS X). For static builds which don't use platform specific optimizations, no configure script is necessary at all; saying make setup ansi make should work on all platforms which have GNU make (or makepp). ---------------------------------------------------------------------- Copyright 2005, 2006, 2007, 2008, 2009, 2010 by David Turner, Robert Wilhelm, and Werner Lemberg. This file is part of the FreeType project, and may only be used, modified, and distributed under the terms of the FreeType project license, LICENSE.TXT. By continuing to use, modify, or distribute this file you indicate that you have read the license and understand and accept it fully. --- end of README.git --- ======================================================================== * freetype builds/amiga/README ======================================================================== README for the builds/amiga subdirectory. Copyright 2005 by Werner Lemberg and Detlef Würkner. This file is part of the FreeType project, and may only be used, modified, and distributed under the terms of the FreeType project license, LICENSE.TXT. By continuing to use, modify, or distribute this file you indicate that you have read the license and understand and accept it fully. The makefile.os4 is for the AmigaOS4 SDK. To use it, type "make -f makefile.os4", it produces a link library libft2_ppc.a. The makefile is for ppc-morphos-gcc-2.95.3-bin.tgz (gcc 2.95.3 hosted on 68k-Amiga producing MorphOS-PPC-binaries from http://www.morphos.de). To use it, type "make assign", then "make"; it produces a link library libft2_ppc.a. The smakefile is a makefile for Amiga SAS/C 6.58 (no longer available, latest sold version was 6.50, updates can be found in Aminet). It is based on the version found in the sourcecode of ttf.library 0.83b for FreeType 1.3.1 from Richard Griffith (ragriffi@sprynet.com, http://ragriffi.home.sprynet.com). You will also need the latest include files and amiga.lib from the Amiga web site (http://www.amiga.com/3.9/download/NDK3.9.lha) for AmigaOS 3.9; the generated code should work under AmigaOS 2.04 and up. To use it, call "smake assign" and then "smake" from the builds/amiga directory. The results are: - A link library "ft2_680x0.lib" (where x depends on the setting of the CPU entry in the smakefile) containing all FreeType2 parts except of the init code, debugging code, and the system interface code. - ftsystem.o, an object module containing the standard version of the system interface code which uses fopen() fclose() fread() fseek() ftell() malloc() realloc() and free() from lib:sc.lib (not pure). - ftsystempure.o, an object module containing the pure version of the system interface code which uses Open() Close() Read() Seek() ExamineFH() AsmAllocPooled() AsmFreePooled() etc. This version can be used in both normal programs and in Amiga run-time shared system librarys (can be linked with lib:libinit.o, no copying of DATA and BSS hunks for each OpenLibrary() necessary). Source code is in src/base/ftsystem.c. - ftdebug.o, an object module containing the standard version of the debugging code which uses vprintf() and exit() (not pure). Debugging can be turned on in FT:include/freetype/config/ftoption.h and with FT_SetTraceLevel(). - ftdebugpure.o, an object module containing the pure version of the debugging code which uses KVPrintf() from lib:debug.lib and no exit(). For debugging of Amiga run-time shared system libraries. Source code is in src/base/ftdebug.c. - NO ftinit.o. Because linking with a link library should result in linking only the needed object modules in it, but standard ftsystem.o would force ALL FreeType2 modules to be linked to your program, I decided to use a different scheme: You must #include FT:src/base/ftinit.c in your sourcecode and specify with #define statements which modules you need. See include/freetype/config/ftmodule.h. To use in your own programs: - Insert the #define and #include statements from top of include/freetype/config/ftmodule.h in your source code and uncomment the #define statements for the FreeType2 modules you need. - You can use either PARAMETERS=REGISTER or PARAMETERS=STACK for calling the FreeType2 functions, because the link library and the object files are compiled with PARAMETERS=BOTH. - "smake assign" (assign "FT:" to the FreeType2 main directory). - Compile your program. - Link with either ftsystem.o or ftsystempure.o, if debugging enabled with either ftdebug.o or (ftdebugpure.o and lib:debug.lib), and with ft2_680x0.lib as link library. To adapt to other compilers: - The standard ANSI C maximum length of 31 significant characters in identifiers is not enough for FreeType2. Check if your compiler has a minimum length of 40 significant characters or can be switched to it. "idlen=40" is the option for SAS/C. Setting #define HAVE_LIMIT_ON_IDENTS in an include file may also work (not tested). - Make sure that the include directory in builds/amiga is searched before the normal FreeType2 include directory, so you are able to replace problematic include files with your own version (same may be useful for the src directory). - An example of how to replace/workaround a problematic include file is include/config/ftconfig.h; it changes a #define that would prevent SAS/C from generating XDEF's where it should do that and then includes the standard FreeType2 include file. Local Variables: coding: latin-1 End: ======================================================================== * freetype src/bdf/README ======================================================================== FreeType font driver for BDF fonts Francesco Zappa Nardelli Introduction ************ BDF (Bitmap Distribution Format) is a bitmap font format defined by Adobe, which is intended to be easily understood by both humans and computers. This code implements a BDF driver for the FreeType library, following the Adobe Specification V 2.2. The specification of the BDF font format is available from Adobe's web site: http://partners.adobe.com/public/developer/en/font/5005.BDF_Spec.pdf Many good bitmap fonts in bdf format come with XFree86 (www.XFree86.org). They do not define vertical metrics, because the X Consortium BDF specification has removed them. Encodings ********* The variety of encodings that accompanies bdf fonts appears to encompass the small set defined in freetype.h. On the other hand, two properties that specify encoding and registry are usually defined in bdf fonts. I decided to make these two properties directly accessible, leaving to the client application the work of interpreting them. For instance: #include FT_INTERNAL_BDF_TYPES_H FT_Face face; BDF_Public_Face bdfface; FT_New_Face( library, ..., &face ); bdfface = (BDF_Public_Face)face; if ( ( bdfface->charset_registry == "ISO10646" ) && ( bdfface->charset_encoding == "1" ) ) [..] Thus the driver always exports `ft_encoding_none' as face->charmap.encoding. FT_Get_Char_Index's behavior is unmodified, that is, it converts the ULong value given as argument into the corresponding glyph number. If the two properties are not available, Adobe Standard Encoding should be assumed. Anti-Aliased Bitmaps ******************** The driver supports an extension to the BDF format as used in Mark Leisher's xmbdfed bitmap font editor. Microsoft's SBIT tool expects bitmap fonts in that format for adding anti-aliased them to TrueType fonts. It introduces a fourth field to the `SIZE' keyword which gives the bpp value (bits per pixel) of the glyph data in the font. Possible values are 1 (the default), 2 (four gray levels), 4 (16 gray levels), and 8 (256 gray levels). The driver returns either a bitmap with 1 bit per pixel or a pixmap with 8bits per pixel (using 4, 16, and 256 gray levels, respectively). Known problems ************** - A font is entirely loaded into memory. Obviously, this is not the Right Thing(TM). If you have big fonts I suggest you convert them into PCF format (using the bdftopcf utility): the PCF font drive of FreeType can perform incremental glyph loading. When I have some time, I will implement on-demand glyph parsing. - Except for encodings properties, client applications have no visibility of the PCF_Face object. This means that applications cannot directly access font tables and must trust FreeType. - Currently, glyph names are ignored. I plan to give full visibility of the BDF_Face object in an upcoming revision of the driver, thus implementing also glyph names. - As I have never seen a BDF font that defines vertical metrics, vertical metrics are (parsed and) discarded. If you own a BDF font that defines vertical metrics, please let me know (I will implement them in 5-10 minutes). License ******* Copyright (C) 2001-2002 by Francesco Zappa Nardelli Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. *** Portions of the driver (that is, bdflib.c and bdf.h): Copyright 2000 Computing Research Labs, New Mexico State University Copyright 2001-2002, 2011 Francesco Zappa Nardelli Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE COMPUTING RESEARCH LAB OR NEW MEXICO STATE UNIVERSITY BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. Credits ******* This driver is based on excellent Mark Leisher's bdf library. If you find something good in this driver you should probably thank him, not me. ======================================================================== * freetype src/gxvalid/README ======================================================================== gxvalid: TrueType GX validator ============================== 1. What is this --------------- `gxvalid' is a module to validate TrueType GX tables: a collection of additional tables in TrueType font which are used by `QuickDraw GX Text', Apple Advanced Typography (AAT). In addition, gxvalid can validates `kern' tables which have been extended for AAT. Like the otvalid module, gxvalid uses Freetype 2's validator framework (ftvalid). You can link gxvalid with your program; before running your own layout engine, gxvalid validates a font file. As the result, you can remove error-checking code from the layout engine. It is also possible to use gxvalid as a stand-alone font validator; the `ftvalid' test program included in the ft2demo bundle calls gxvalid internally. A stand-alone font validator may be useful for font developers. This documents documents the following issues. - supported TrueType GX tables - fundamental validation limitations - permissive error handling of broken GX tables - `kern' table issue. 2. Supported tables ------------------- The following GX tables are currently supported. bsln feat just kern(*) lcar mort morx opbd prop trak The following GX tables are currently unsupported. cvar fdsc fmtx fvar gvar Zapf The following GX tables won't be supported. acnt(**) hsty(***) The following undocumented tables in TrueType fonts designed for Apple platform aren't handled either. addg CVTM TPNM umif *) The `kern' validator handles both the classic and the new kern formats; the former is supported on both Microsoft and Apple platforms, while the latter is supported on Apple platforms. **) `acnt' tables are not supported by currently available Apple font tools. ***) There is one more Apple extension, `hsty', but it is for Newton-OS, not GX (Newton-OS is a platform by Apple, but it can use sfnt- housed bitmap fonts only). Therefore, it should be excluded from `Apple platform' in the context of TrueType. gxvalid ignores it as Apple font tools do so. We have checked 183 fonts bundled with MacOS 9.1, MacOS 9.2, MacOS 10.0, MacOS X 10.1, MSIE for MacOS, and AppleWorks 6.0. In addition, we have checked 67 Dynalab fonts (designed for MacOS) and 189 Ricoh fonts (designed for Windows and MacOS dual platforms). The number of fonts including TrueType GX tables are as follows. bsln: 76 feat: 191 just: 84 kern: 59 lcar: 4 mort: 326 morx: 19 opbd: 4 prop: 114 trak: 16 Dynalab and Ricoh fonts don't have GX tables except of `feat' and `mort'. 3. Fundamental validation limitations ------------------------------------- TrueType GX provides layout information to libraries for font rasterizers and text layout. gxvalid can check whether the layout data in a font is conformant to the TrueType GX format specified by Apple. But gxvalid cannot check a how QuickDraw GX/AAT renderer uses the stored information. 3-1. Validation of State Machine activity ----------------------------------------- QuickDraw GX/AAT uses a `State Machine' to provide `stateful' layout features, and TrueType GX stores the state transition diagram of this `State Machine' in a `StateTable' data structure. While the State Machine receives a series of glyph IDs, the State Machine starts with `start of text' state, walks around various states and generates various layout information to the renderer, and finally reaches the `end of text' state. gxvalid can check essential errors like: - possibility of state transitions to undefined states - existence of glyph IDs that the State Machine doesn't know how to handle - the State Machine cannot compute the layout information from given diagram These errors can be checked within finite steps, and without the State Machine itself, because these are `expression' errors of state transition diagram. There is no limitation about how long the State Machine walks around, so validation of the algorithm in the state transition diagram requires infinite steps, even if we had a State Machine in gxvalid. Therefore, the following errors and problems cannot be checked. - existence of states which the State Machine never transits to - the possibility that the State Machine never reaches `end of text' - the possibility of stack underflow/overflow in the State Machine (in ligature and contextual glyph substitutions, the State Machine can store 16 glyphs onto its stack) In addition, gxvalid doesn't check `temporary glyph IDs' used in the chained State Machines (in `mort' and `morx' tables). If a layout feature is implemented by a single State Machine, a glyph ID converted by the State Machine is passed to the glyph renderer, thus it should not point to an undefined glyph ID. But if a layout feature is implemented by chained State Machines, a component State Machine (if it is not the final one) is permitted to generate undefined glyph IDs for temporary use, because it is handled by next component State Machine and not by the glyph renderer. To validate such temporary glyph IDs, gxvalid must stack all undefined glyph IDs which can occur in the output of the previous State Machine and search them in the `ClassTable' structure of the current State Machine. It is too complex to list all possible glyph IDs from the StateTable, especially from a ligature substitution table. 3-2. Validation of relationship between multiple layout features ---------------------------------------------------------------- gxvalid does not validate the relationship between multiple layout features at all. If multiple layout features are defined in TrueType GX tables, possible interactions, overrides, and conflicts between layout features are implicitly given in the font too. For example, there are several predefined spacing control features: - Text Spacing (Proportional/Monospace/Half-width/Normal) - Number Spacing (Monospaced-numbers/Proportional-numbers) - Kana Spacing (Full-width/Proportional) - Ideographic Spacing (Full-width/Proportional) - CJK Roman Spacing (Half-width/Proportional/Default-roman /Full-width-roman/Proportional) If all layout features are independently managed, we can activate inconsistent typographic rules like `Text Spacing=Monospace' and `Ideographic Spacing=Proportional' at the same time. The combinations of layout features is managed by a 32bit integer (one bit each for selector setting), so we can define relationships between up to 32 features, theoretically. But if one feature setting affects another feature setting, we need typographic priority rules to validate the relationship. Unfortunately, the TrueType GX format specification does not give such information even for predefined features. 4. Permissive error handling of broken GX tables ------------------------------------------------ When Apple's font rendering system finds an inconsistency, like a specification violation or an unspecified value in a TrueType GX table, it does not always return error. In most cases, the rendering engine silently ignores such wrong values or even whole tables. In fact, MacOS is shipped with fonts including broken GX/AAT tables, but no harmful effects due to `officially broken' fonts are observed by end-users. gxvalid is designed to continue the validation process as long as possible. When gxvalid find wrong values, gxvalid warns it at least, and takes a fallback procedure if possible. The fallback procedure depends on the debug level. We used the following three tools to investigate Apple's error handling. - FontValidator (for MacOS 8.5 - 9.2) resource fork font - ftxvalidator (for MacOS X 10.1 -) dfont or naked-sfnt - ftxdumperfuser (for MacOS X 10.1 -) dfont or naked-sfnt However, all tests were done on a PowerPC based Macintosh; at present, we have not checked those tools on a m68k-based Macintosh. In total, we checked 183 fonts bundled to MacOS 9.1, MacOS 9.2, MacOS 10.0, MacOS X 10.1, MSIE for MacOS, and AppleWorks 6.0. These fonts are distributed officially, but many broken GX/AAT tables were found by Apple's font tools. In the following, we list typical violation of the GX specification, in fonts officially distributed with those Apple systems. 4-1. broken BinSrchHeader (19/183) ---------------------------------- `BinSrchHeader' is a header of a data array for m68k platforms to access memory efficiently. Although there are only two independent parameters for real (`unitSize' and `nUnits'), BinSrchHeader has three additional parameters which can be calculated from `unitSize' and `nUnits', for fast setup. Apple font tools ignore them silently, so gxvalid warns if it finds and inconsistency, and always continues validation. The additional parameters are ignored regardless of the consistency. 19 fonts include such inconsistencies; all breaks are in the BinSrchHeader structure of the `kern' table. 4-2. too-short LookupTable (5/183) ---------------------------------- LookupTable format 0 is a simple array to get a value from a given GID (glyph ID); the index of this array is a GID too. Therefore, the length of the array is expected to be same as the maximum GID value defined in the `maxp' table, but there are some fonts whose LookupTable format 0 is too short to cover all GIDs. FontValidator ignores this error silently, ftxvalidator and ftxdumperfuser both warn and continue. Similar problems are found in format 3 subtables of `kern'. gxvalid warns always and abort if the validation level is set to FT_VALIDATE_PARANOID. 5 fonts include too-short kern format 0 subtables. 1 font includes too-short kern format 3 subtable. 4-3. broken LookupTable format 2 (1/183) ---------------------------------------- LookupTable format 2, subformat 4 covers the GID space by a collection of segments which are specified by `firstGlyph' and `lastGlyph'. Some fonts store `firstGlyph' and `lastGlyph' in reverse order, so the segment specification is broken. Apple font tools ignore this error silently; a broken segment is ignored as if it did not exist. gxvalid warns and normalize the segment at FT_VALIDATE_DEFAULT, or ignore the segment at FT_VALIDATE_TIGHT, or abort at FT_VALIDATE_PARANOID. 1 font includes broken LookupTable format 2, in the `just' table. *) It seems that all fonts manufactured by ITC for AppleWorks have this error. 4-4. bad bracketing in glyph property (14/183) ---------------------------------------------- GX/AAT defines a `bracketing' property of the glyphs in the `prop' table, to control layout features of strings enclosed inside and outside of brackets. Some fonts give inappropriate bracket properties to glyphs. Apple font tools warn about this error; gxvalid warns too and aborts at FT_VALIDATE_PARANOID. 14 fonts include wrong bracket properties. 4-5. invalid feature number (117/183) ------------------------------------- The GX/AAT extension can include 255 different layout features, but popular layout features are predefined (see http://developer.apple.com/fonts/Registry/index.html). Some fonts include feature numbers which are incompatible with the predefined feature registry. In our survey, there are 140 fonts including `feat' table. a) 67 fonts use a feature number which should not be used. b) 117 fonts set the wrong feature range (nSetting). This is mostly found in the `mort' and `morx' tables. Apple font tools give no warning, although they cannot recognize what the feature is. At FT_VALIDATE_DEFAULT, gxvalid warns but continues in both cases (a, b). At FT_VALIDATE_TIGHT, gxvalid warns and aborts for (a), but continues for (b). At FT_VALIDATE_PARANOID, gxvalid warns and aborts in both cases (a, b). 4-6. invalid prop version (10/183) ---------------------------------- As most TrueType GX tables, the `prop' table must start with a 32bit version identifier: 0x00010000, 0x00020000 or 0x00030000. But some fonts store nonsense binary data instead. When Apple font tools find them, they abort the processing immediately, and the data which follows is unhandled. gxvalid does the same. 10 fonts include broken `prop' version. All of these fonts are classic TrueType fonts for the Japanese script, manufactured by Apple. 4-7. unknown resource name (2/183) ------------------------------------ NOTE: THIS IS NOT A TRUETYPE GX ERROR. If a TrueType font is stored in the resource fork or in dfont format, the data must be tagged as `sfnt' in the resource fork index to invoke TrueType font handler for the data. But the TrueType font data in `Keyboard.dfont' is tagged as `kbd', and that in `LastResort.dfont' is tagged as `lst'. Apple font tools can detect that the data is in TrueType format and successfully validate them. Maybe this is possible because they are known to be dfont. The current implementation of the resource fork driver of FreeType cannot do that, thus gxvalid cannot validate them. 2 fonts use an unknown tag for the TrueType font resource. 5. `kern' table issues ---------------------- In common terminology of TrueType, `kern' is classified as a basic and platform-independent table. But there are Apple extensions of `kern', and there is an extension which requires a GX state machine for contextual kerning. Therefore, gxvalid includes a special validator for `kern' tables. Unfortunately, there is no exact algorithm to check Apple's extension, so gxvalid includes a heuristic algorithm to find the proper validation routines for all possible data formats, including the data format for Microsoft. By calling classic_kern_validate() instead of gxv_validate(), you can specify the `kern' format explicitly. However, current FreeType2 uses Microsoft `kern' format only, others are ignored (and should be handled in a library one level higher than FreeType). 5-1. History ------------ The original 16bit version of `kern' was designed by Apple in the pre-GX era, and it was also approved by Microsoft. Afterwards, Apple designed a new 32bit version of the `kern' table. According to the documentation, the difference between the 16bit and 32bit version is only the size of variables in the `kern' header. In the following, we call the original 16bit version as `classic', and 32bit version as `new'. 5-2. Versions and dialects which should be differentiated --------------------------------------------------------- The `kern' table consists of a table header and several subtables. The version number which identifies a `classic' or a `new' version is explicitly written in the table header, but there are undocumented differences between Microsoft's and Apple's formats. It is called a `dialect' in the following. There are three cases which should be handled: the new Apple-dialect, the classic Apple-dialect, and the classic Microsoft-dialect. An analysis of the formats and the auto detection algorithm of gxvalid is described in the following. 5-2-1. Version detection: classic and new kern ---------------------------------------------- According to Apple TrueType specification, there are only two differences between the classic and the new: - The `kern' table header starts with the version number. The classic version starts with 0x0000 (16bit), the new version starts with 0x00010000 (32bit). - In the `kern' table header, the number of subtables follows the version number. In the classic version, it is stored as a 16bit value. In the new version, it is stored as a 32bit value. From Apple font tool's output (DumpKERN is also tested in addition to the three Apple font tools in above), there is another undocumented difference. In the new version, the subtable header includes a 16bit variable named `tupleIndex' which does not exist in the classic version. The new version can store all subtable formats (0, 1, 2, and 3), but the Apple TrueType specification does not mention the subtable formats available in the classic version. 5-2-2. Available subtable formats in classic version ---------------------------------------------------- Although the Apple TrueType specification recommends to use the classic version in the case if the font is designed for both the Apple and Microsoft platforms, it does not document the available subtable formats in the classic version. According to the Microsoft TrueType specification, the subtable format assured for Windows and OS/2 support is only subtable format 0. The Microsoft TrueType specification also describes subtable format 2, but does not mention which platforms support it. Aubtable formats 1, 3, and higher are documented as reserved for future use. Therefore, the classic version can store subtable formats 0 and 2, at least. `ttfdump.exe', a font tool provided by Microsoft, ignores the subtable format written in the subtable header, and parses the table as if all subtables are in format 0. `kern' subtable format 1 uses a StateTable, so it cannot be utilized without a GX State Machine. Therefore, it is reasonable to assume that format 1 (and 3) were introduced after Apple had introduced GX and moved to the new 32bit version. 5-2-3. Apple and Microsoft dialects ----------------------------------- The `kern' subtable has a 16bit `coverage' field to describe kerning attributes, but bit interpretations by Apple and Microsoft are different: For example, Apple uses bits 0-7 to identify the subtable, while Microsoft uses bits 8-15. In addition, due to the output of DumpKERN and FontValidator, Apple's bit interpretations of coverage in classic and new version are incompatible also. In summary, there are three dialects: classic Apple dialect, classic Microsoft dialect, and new Apple dialect. The classic Microsoft dialect and the new Apple dialect are documented by each vendors' TrueType font specification, but the documentation for classic Apple dialect is not available. For example, in the new Apple dialect, bit 15 is documented as `set to 1 if the kerning is vertical'. On the other hand, in classic Microsoft dialect, bit 1 is documented as `set to 1 if the kerning is horizontal'. From the outputs of DumpKERN and FontValidator, classic Apple dialect recognizes 15 as `set to 1 when the kerning is horizontal'. From the results of similar experiments, classic Apple dialect seems to be the Endian reverse of the classic Microsoft dialect. As a conclusion it must be noted that no font tool can identify classic Apple dialect or classic Microsoft dialect automatically. 5-2-4. gxvalid auto dialect detection algorithm ----------------------------------------------- The first 16 bits of the `kern' table are enough to identify the version: - if the first 16 bits are 0x0000, the `kern' table is in classic Apple dialect or classic Microsoft dialect - if the first 16 bits are 0x0001, and next 16 bits are 0x0000, the kern table is in new Apple dialect. If the `kern' table is a classic one, the 16bit `coverage' field is checked next. Firstly, the coverage bits are decoded for the classic Apple dialect using the following bit masks (this is based on DumpKERN output): 0x8000: 1=horizontal, 0=vertical 0x4000: not used 0x2000: 1=cross-stream, 0=normal 0x1FF0: reserved 0x000F: subtable format If any of reserved bits are set or the subtable bits is interpreted as format 1 or 3, we take it as `impossible in classic Apple dialect' and retry, using the classic Microsoft dialect. The most popular coverage in new Apple-dialect: 0x8000, The most popular coverage in classic Apple-dialect: 0x0000, The most popular coverage in classic Microsoft dialect: 0x0001. 5-3. Tested fonts ----------------- We checked 59 fonts bundled with MacOS and 38 fonts bundled with Windows, where all font include a `kern' table. - fonts bundled with MacOS * new Apple dialect format 0: 18 format 2: 1 format 3: 1 * classic Apple dialect format 0: 14 * classic Microsoft dialect format 0: 15 - fonts bundled with Windows * classic Microsoft dialect format 0: 38 It looks strange that classic Microsoft-dialect fonts are bundled to MacOS: they come from MSIE for MacOS, except of MarkerFelt.dfont. ACKNOWLEDGEMENT --------------- Some parts of gxvalid are derived from both the `gxlayout' module and the `otvalid' module. Development of gxlayout was supported by the Information-technology Promotion Agency(IPA), Japan. The detailed analysis of undefined glyph ID utilization in `mort' and `morx' tables is provided by George Williams. ------------------------------------------------------------------------ Copyright 2004, 2005, 2007 by suzuki toshiya, Masatake YAMATO, Red hat K.K., David Turner, Robert Wilhelm, and Werner Lemberg. This file is part of the FreeType project, and may only be used, modified, and distributed under the terms of the FreeType project license, LICENSE.TXT. By continuing to use, modify, or distribute this file you indicate that you have read the license and understand and accept it fully. --- end of README --- ======================================================================== * freetype src/pcf/README ======================================================================== FreeType font driver for PCF fonts Francesco Zappa Nardelli Introduction ************ PCF (Portable Compiled Format) is a binary bitmap font format, largely used in X world. This code implements a PCF driver for the FreeType library. Glyph images are loaded into memory only on demand, thus leading to a small memory footprint. Information on the PCF font format can only be worked out from `pcfread.c', and `pcfwrite.c', to be found, for instance, in the XFree86 (www.xfree86.org) source tree (xc/lib/font/bitmap/). Many good bitmap fonts in bdf format come with XFree86: they can be compiled into the pcf format using the `bdftopcf' utility. Supported hardware ****************** The driver has been tested on linux/x86 and sunos5.5/sparc. In both cases the compiler was gcc. When back in Paris, I will test it also on linux/alpha. Encodings ********* Use `FT_Get_BDF_Charset_ID' to access the encoding and registry. The driver always exports `ft_encoding_none' as face->charmap.encoding. FT_Get_Char_Index() behavior is unmodified, that is, it converts the ULong value given as argument into the corresponding glyph number. Known problems ************** - dealing explicitly with encodings breaks the uniformity of freetype2 api. - except for encodings properties, client applications have no visibility of the PCF_Face object. This means that applications cannot directly access font tables and are obliged to trust FreeType. - currently, glyph names and ink_metrics are ignored. I plan to give full visibility of the PCF_Face object in the next release of the driver, thus implementing also glyph names and ink_metrics. - height is defined as (ascent - descent). Is this correct? - if unable to read size information from the font, PCF_Init_Face sets available_size->width and available_size->height to 12. - too many english grammar errors in the readme file :-( License ******* Copyright (C) 2000 by Francesco Zappa Nardelli Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. Credits ******* Keith Packard wrote the pcf driver found in XFree86. His work is at the same time the specification and the sample implementation of the PCF format. Undoubtedly, this driver is inspired from his work. ======================================================================== * freetype docs/GPLv2.TXT ======================================================================== GNU GENERAL PUBLIC LICENSE Version 2, June 1991 Copyright (C) 1989, 1991 Free Software Foundation, Inc. 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 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 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. Copyright (C) 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., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 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) year 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. , 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. ======================================================================== * freetype docs/LICENSE.TXT ======================================================================== 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. Note that this license is compatible to the GNU General Public License version 3, but not version 2. - The GNU General Public License version 2, found in `GPLv2.TXT' (any later version can be used also), for programs which already use the GPL. Note that the FTL is incompatible with GPLv2 due to its advertisement clause. The contributed BDF and PCF drivers come with a license similar to that of the X Window System. It is compatible to the above two licenses (see file src/bdf/README and src/pcf/README). The gzip module uses the zlib license (see src/gzip/zlib.h) which too is compatible to the above two licenses. --- end of LICENSE.TXT ---