Featured content is also available via:

Clean up FreeType outsourcing leftovers

Operating Systems / Haiku - luroh [gmail.com] - 5 January 2015 04:23 UTC

- Remove obsolete FreeType docs- Remove obsolete FreeType license- Update FreeType license and copyrights in AboutSystem

###

diff --git a/data/system/data/licenses/FTL b/data/system/data/licenses/FTL
deleted file mode 100644
index 0967302..0000000
--- a/data/system/data/licenses/FTL
+++ /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
- Robert Wilhelm
- Werner Lemberg
-
-
---- end of LICENSE.TXT ---
diff --git a/docs/freetype2/BUGS b/docs/freetype2/BUGS
deleted file mode 100644
index bb68c68..0000000
--- a/docs/freetype2/BUGS
+++ /dev/null
@@ -1,275 +0,0 @@
-List of known FreeType 2 Bugs
------------------------------
-
-"Identifier" is a string to uniquely identify the bug. A more detailed
-description of the bug is found below the table of opened bugs.
-
-"Date" is the date when the bug was first reported or entered in this
-document. Dates are in _European_ format, i.e day/month/year.
-
-"Opened By" is the name of the person who first spotted the bug. Note that
-we can use abbreviations here, like:
-
- "David" for David Turner
- "Werner" for Werner Lemberg
- etc.
-
-"Reproduceable" indicates whether the bug could be reproduced by the
-development team or not (it can be specific to a given platform), whether it
-always happens, or only sporadically, etc.
-
-
-
-I. Open bugs
-============
-
-
-Identifier Date Opened by Reproduceable
-------------------------------------------------------------------------------
-NO-CID-CMAPS 13-09-2001 David always
-BAD-TT-RENDERING 12-09-2001 Paul Pedriana ?
-BAD-THIN-LINES 13-09-2001 David ?
-NOT-WINDOWS-METRICS 07-10-2001 David always
-ADVANCED-COMPOSITES 25-10-2001 George Williams always
-
---------------------END-OF-OPENED-BUGS-TABLE----------------------------------
-
-
-
-II. Closed bugs
-===============
-
-
-Identifier Date Closed by Closure date
-------------------------------------------------------------------------------
-BAD-TTNAMEID.H 12-09-2001 Antoine N/A
-BAD-T1-CHARMAP 15-06-2001 David 2.0.5
-BAD-UNIXXXX-NAMES 30-07-2001 David 2.0.5
-GLYPH_TO_BITMAP-BUG 05-12-2001 David 05-12-2001
-AUTOHINT-NO-SBITS 13-09-2001 David 2.0.6
-TT-GLYPH-CRASH 01-01-2002 David 2.0.6
-T1-FONT-CRASH 01-01-2002 David 2.0.6
-BAD-ADVANCES 30-11-2001 David 2.0.6
-GLYPH-TO-BITMAP-BUG 15-12-2001 David 2.0.6
---------------------END-OF-CLOSED-BUGS-TABLE----------------------------------
-
-
-
-III. Bug descriptions
-=====================
-
-
---- START OF OPEN BUGS ---
-
-
-NO-CID-CMAPS
-
- Not exactly a bug, but the CFF font driver doesn't build a Unicode charmap
- from the contents of font files, which prevents efficiently using fonts in
- this format.
-
-
-
-BAD-TT-RENDERING
-
- According to Paul Pedriana , there is a rather
- important difference between the rendering of TrueType-hinted glyphs of
- current FT2 and old betas.
-
- Tests and comparisons show a _major_ discrepancy of monochrome truetype
- bytecode-hinted glyphs! Something seems to be really broken here!
-
- Some of this has been fixed in 2.0.6; there was a bug in the TrueType
- loader that prevented it from loading composites correctly. However,
- there are still _subtle_ differences between FT1 and FT2 when it comes to
- monochrome TrueType-hinted glyphs (the major differences are gone though).
-
-
-
-BAD-THIN-LINES
-
- It seems that the anti-aliased renderer in FreeType has problems rendering
- extremely thin straight lines correctly, at least when using the
- FT_Outline_Render() function.
-
-
-
-NOT-WINDOWS-METRICS
-
- FreeType doesn't always return the same metrics as Windows for ascender,
- descender, and text height, depending on character pixel sizes. A lot of
- testing on Windows is needed to debug this properly. It might be due to a
- rounding bug when computing the "x_scale" and "y_scale" values.
-
-
-
-ADVANCED-COMPOSITES
-
- Provided by George Williams :
-
- I notice that truetype/ttgload.c only supports Apple's definition of
- offsets for composite glyphs. Apple and Microsoft behave differently if
- there is a scale factor. OpenType defines some bits to disambiguate.
-
- (A problem in both 2.0.4 and 2.0.5.)
-
- Apple says (http://fonts.apple.com/TTRefMan/RM06/Chap6glyf.html) that if
- flags&ARGS_ARE_XY is set then the offsets should be scaled by the scale
- factors (as you have done), but they also say something very cryptic
- about what happens when the component is rotated at 45° (which you do
- not support) -- See the "Important" note at the bottom.
-
- The old truetype spec from Microsoft did not mention this. The OpenType
- spec (http://www.microsoft.com/typography/otspec/glyf.htm,
- http://partners.adobe.com/asn/developer/opentype/glyf.html) defines two
- new bits to disambiguate:
-
- SCALED_COMPONENT_OFFSET 11
- Composite designed to have the component offset scaled (designed for
- Apple rasterizer)
-
- UNSCALED_COMPONENT_OFFSET 12
- Composite designed not to have the component offset scaled (designed
- for the Microsoft TrueType rasterizer)
-
- Perhaps you could add a load_flag to allow the user to define the
- default setting?
-
- David says:
-
- Wow, I was not even aware of this, it will probably take a little time
- to implement since I don't have any font that implement these
- "features", and also because I believe that we're running out of bits
- for "load_flag", some other way to set preferences is probably needed.
-
-
-
---- END OF OPEN BUGS ---
-
-
-
-BAD-TTNAMEID.H
-
- The file "ttnameid.h" contains various constant macro definitions
- corresponding to important values defined by the TrueType specification.
-
- Joe Man reports that:
-
- According to the information from TrueType v1.66:
-
- Platform ID = 3 (Microsoft)
- the Encoding ID of GB2312 = 4
- the Encoding ID of big5 = 3
-
- However, I have found that in ttnameid.h:
-
- TT_MS_ID_GB2312 = 3
- TT_MS_ID_BIG_5 = 4
-
- Which one is correct?
-
- Antoine replied that this was a bug in the TT 1.66 specification, and that
- FreeType followed the most recent TrueType/OpenType specification here.
-
-
-
-AUTOHINT-SBITS
-
- When trying to load a glyph, with the auto-hinter activated (i.e., when
- using FT_LOAD_FORCE_AUTOHINT, or when the font driver doesn't provide its
- own hinter), embedded bitmaps are _never_ loaded, unlike the default
- behaviour described by the API specification.
-
- This seems to be a bug in FT_Load_Glyph(), but there is no way to solve it
- efficiently without making a few important internal changes to the
- library's design (more importantly, to the font driver interface).
-
- This has been corrected with a hack in FT_Load_Glyph(). More important
- internal changes should help get rid of it with a clean solution in a
- further release like FreeType 2.1.
-
-
-
-BAD-T1-CHARMAP
-
- Type1 driver doesn't read "cacute" and "lslash" characters from iso8859-2
- charset. Those characters are mapped as MAC-one in glnames.py, so they
- cannot be shown in Adobe Type1 fonts.
-
- (This was due to a bug in the "glnames.py" script used to generate the
- table of glyph names in 'src/psaux/pstables.h'.)
-
-
-
-BAD-UNIXXXX-NAMES
-
- Glyph names like uniXXXX are not recognized as they should be. It seems
- that code in psmodule.c for uniXXXX glyph names was never tested. The
- patch is very simple.
-
- (A simple bug that was left un-noticed due to the fact that I don't have
- any Postscript font that use this convention, unfortunately.)
-
-
-
-GLYPH_TO_BITMAP-BUG
-
- Calling FT_Glyph_To_Bitmap() sometimes modifies the original glyph
- outline, creating weird alignment artefacts.
-
- This subtle bug was really in the file `src/smooth/ftsmooth.c'.
- Basically, the outline was shifted before rendering it into a new bitmap
- buffer. However, it wasn't properly un-shifted after that operation.
-
- This was only noticeable with certain glyphs or certain fonts; it crept in
- a long time ago.
-
- The same bug has been fixed in src/raster/ftrender1.c also.
-
-
-
-TT-GLYPH-CRASH
-
- The library crashed when trying to load certain glyphs from an
- automatically generated TrueType file (tt1095m_.ttf submitted by Scott
- Long).
-
- It turned out that the font contained invalid glyph data (i.e. was
- broken), but the TrueType glyph loader in FreeType wasn't paranoid enough,
- which resulted in nasty memory overwrites all over the place.
-
-
-
-T1-FONT-CRASH
-
- The library crashed when trying to load the "Stalingrad Regular" face from
- the "sadn.pfb" font file provided by Anthony Fok (and the Gnome-Print team
- I believe).
-
- This was due to the fact that the font missed a full font name entry,
- though boasted a family name and postscript name. The Type 1 face loader
- didn't check for these pathetic cases and seg-faulted.
-
-
-
-BAD-ADVANCES
-
- All scalable font drivers returned un-fitted glyph advances when
- FT_LOAD_DEFAULT was used, which was incorrect. This problem was pretty
- old but hadn't been spotted because all test programs actually explicitly
- or implicitly (i.e. through the cache) rounded the advance widths of
- glyphs.
-
- This resulted in poor rendering of a number of client applications however
- (it is strange to see they took so long to notify the FreeType team).
-
-
-
-GLYPH-TO-BITMAP-BUG
-
- FT_Glyph_To_Bitmap() did incorrectly modify the source glyph in certain
- cases, which resulted in random behaviour and bad text rendering. This
- was spotted to bugs in both the monochrome and smooth rasterizer.
-
-
-=== end of file ===
diff --git a/docs/freetype2/BUILD b/docs/freetype2/BUILD
deleted file mode 100644
index 7bf70bf..0000000
--- a/docs/freetype2/BUILD
+++ /dev/null
@@ -1,276 +0,0 @@
-
- FreeType 2 compilation how-to
- =============================
-
-
-Introduction
-------------
-
-Welcome to the FreeType 2 library. You'll find in this document
-instructions on how to compile the library on your favorite platform.
-
-
-I. QUICK COMMAND-LINE GUIDE
----------------------------
-
- THE FOLLOWING WILL ONLY WORK WITH GNU MAKE, IT WILL FAIL MISERABLY
- WITH OTHER MAKE TOOLS, FOR EXAMPLE "BSD MAKE".
-
- Install GNU Make (version 3.78.1 or newer), then try the following
- on Unix or any system with gcc:
-
- make // this will setup the build
- make // this will build the library
-
- On Win32 + Visual C++:
-
- make setup visualc // setup the build for VisualC++ on Win32
- make // build the library
-
- Then, go to the `demos' directory and type
-
- make
-
-
- Note that on Unix, the first `make' invocation will run a configure
- script (which is located in `freetype2/builds/unix/'. You can also
- pass parameters to this script with the CFG variable, as in:
-
- make CFG="--prefix=/usr/local"
- make
-
-
- If this doesn't work, read the following.
-
-
-II. COMMAND-LINE COMPILATION
-----------------------------
-
- Note that if you do not want to compile FreeType 2 from a command
- line shell, please skip to section III below (DETAILED COMPILATION).
-
- 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:
-
- a. 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!
-
- 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!
-
- b. 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 e. Note that if your platform is completely alien to
- the build system, the detected platform will be `ansi'.
-
- c. 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
-
- For example:
-
- to use Visual C++ on Win32, type: "make setup visualc"
- to use LCC-Win32 on Win32, type: "make setup lcc"
-
- The name to use is platform-dependent. The list of
- available compilers for your system is available in the file
- `builds//detect.mk' (note that we hope to make the list
- displayed at user demand in the final release).
-
- If you are satisfied by the new configuration summary, skip to
- step e.
-
- d. 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 e.
-
- 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'.
-
- e. 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.
-
- f. Build the demonstration programs
-
-
-III. DETAILED COMPILATION PROCEDURE
------------------------------------
-
- If you don't want to compile FreeType 2 from the command-line (for
- example if you use a graphical IDE on a Mac or Windows), you will
- need to understand how the FreeType files are organized.
-
- FreeType 2 has a very modular design, and it is made of several
- components. Each component must be compiled as a stand-alone object
- file, even if it is really made of several C source files. For
- example, the `base layer' component is made of the following C
- files:
-
- src/
- base/
- ftcalc.c - computations
- ftextend.c - extensions support
- ftlist.c - simple list management
- ftobjs.c - object management
- ftoutln.c - simple outline processing
- ftstream.c - stream input
-
- However, you can create a single object file by compiling the file
- `src/base/ftbase.c', which basically contains
-
- #include "ftcalc.c"
- #include "ftobjs.c"
- #include "ftstream.c"
- #include "ftlist.c"
- #include "ftoutln.c"
- #include "ftextend.c"
-
- Similarly, each component has a single `englobing' C file to compile
- it as a stand-alone object:
-
- src/autohint/autohint.c - the autohinting module
- src/base/ftbase.c - the base layer, high-level interface
- src/cache/ftcache.c - a glyph and image caching system
- (still experimental)
- src/cff/cff.c - the OpenType font driver
- src/cid/type1cid.c - the CID-keyed font driver
- src/psaux/psaux.c - the PS support module
- src/psnames/psnames.c - a support module to handle PS glyph
- names
- src/raster1/raster1.c - the monochrome raster module
- src/sfnt/sfnt.c - the `sfnt' module
- src/smooth/smooth.c - the anti-aliasing raster module
- src/truetype/truetype.c - the TrueType font driver
- src/type1/type1.c - the Type 1 font driver
-
- The last module of FreeType 2, `winfonts' (implementing support for
- Windows FNT format), is a single file.
-
- To compile one component, do the following:
-
- - Add the top-level `include' directory to your compilation
- include path
-
- - Add the `src/' directory to your compilation include
- path, or simply `cd' to the component's source directory.
-
- - Compile the component `source' file (see list below); you don't
- need to be in the component's directory if you added
- `src/' to your include path.
-
- For example, the following line can be used to compile the truetype
- driver on Unix:
-
- cd freetype2/
- cc -c -Iinclude -Isrc/truetype src/truetype/truetype.c
-
- Alternatively:
-
- cd freetype2/src/truetype
- cc -c -I../../include truetype.c
-
- Finally, FreeType 2 contains some other components:
-
- src/base/ftsystem.c - system-specific memory and i/o support
- src/base/ftinit.c - initialization layer
- src/base/ftdebug.c - debugging component (empty in release
- build)
- src/base/ftglyph.c - optional convenience functions
-
- All font drivers are optional. The `sfnt', `psaux', and `psnames'
- modules are mandatory for certain drivers. However, you may need to
- update the list of drivers that are statically linked to the
- library, which is located in the configuration file
- `include/freetype/config/ftmodule.h'.
-
-
-IV. 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 file
diff --git a/docs/freetype2/CHANGES b/docs/freetype2/CHANGES
deleted file mode 100644
index 26138b2..0000000
--- a/docs/freetype2/CHANGES
+++ /dev/null
@@ -1,1953 +0,0 @@
-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 transform
- 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'll 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=
- 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
- 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_