KIKIMR-19287: add task_stats_drawing script

14 files changed, 8092 insertions, 0 deletions

diff --git a/contrib/libs/freetype/docs/CHANGES b/contrib/libs/freetype/docs/CHANGES
new file mode 100644
index 0000000000..96cf607d70
--- /dev/null
+++ b/contrib/libs/freetype/docs/CHANGES
@@ -0,0 +1,5686 @@
+CHANGES BETWEEN 2.13.1 and 2.13.2 (2023-Aug-25)
+
+  I. MISCELLANEOUS
+
+  - Better support for CFF2 variation fonts.
+
+  - TrueType interpreter  version 38 (also known  as 'Infinality') has
+    been removed.
+
+  - Improved OpenVMS support.
+
+
+======================================================================
+
+CHANGES BETWEEN 2.13.0 and 2.13.1 (2023-Jun-24)
+
+  I. MISCELLANEOUS
+
+  - New function  `FT_Get_Default_Named_Instance` to get the  index of
+    the default named instance of an OpenType Variation Font.
+
+  - A new load flag `FT_LOAD_NO_SVG` to make FreeType ignore glyphs in
+    an 'SVG ' table.
+
+  - New  function  `FT_GlyphSlot_AdjustWeight`  to  adjust  the  glyph
+    weight either  horizontally or  vertically.  This  is part  of the
+    `ftsynth.h` header file, which is  still considered to be in alpha
+    stage.
+
+  - TrueType interpreter  version 38 (also known  as 'Infinality') has
+    been deactivated; the value  of `TT_INTERPRETER_VERSION_38` is now
+    the same as `TT_INTERPRETER_VERSION_40`.
+
+  - Updated OpenVMS support.
+
+  - The  base  API  documentation  has  been  modularized  for  easier
+    handling.
+
+  - Switching named instances on and  off in Variation Fonts was buggy
+    if the design coordinates didn't change.
+
+  - `ftbench`  has a  new  command-line option  `-a`  to apply  design
+    coordinates.
+
+  - `ftview` can now flip SVG rendering on and off using the 'Z' key.
+
+  - In  `ftmulti` it  is  now possible  to toggle  the  fill rule  and
+    overlap flag  used for  rendering glyphs using  the 'F3'  and 'F4'
+    keys,  respectively.   Toggling  the anti-aliased  mode  has  been
+    changed to the 'TAB' key.
+
+
+======================================================================
+
+CHANGES BETWEEN 2.12.1 and 2.13.0 (2023-Feb-09)
+
+  I. IMPORTANT CHANGES
+
+  - The demo program `ftinspect` has  been completely updated and much
+    enhanced.  It now  combines the functionality of  almost all other
+    graphical FreeType  demo programs into a  single application based
+    on the Qt framework.  This was Charlie Jiang's GSoC 2022 project.
+
+  - The 'COLR' v1 API is now considered as stable.
+
+      https://learn.microsoft.com/en-us/typography/opentype/spec/colr
+
+
+  II. MISCELLANEOUS
+
+  - For  OpenType  Variable Fonts,  `avar`  table  format 2.0  is  now
+    supported.  The code was contributed by Behdad Esfahbod.
+
+    Note that this is an extension supported on recent Apple platforms
+    and by HarfBuzz, but not yet in the OpenType standard!  See
+
+      https://github.com/harfbuzz/boring-expansion-spec/blob/main/avar2.md
+
+    for the specification.  To deactivate it, define the configuration
+    macro 'TT_CONFIG_OPTION_NO_BORING_EXPANSION'.
+
+  - A new API  `FT_GlyphSlot_Slant` to slant a glyph by  a given angle
+    has been added.   Note that this function is  part of `ftsynth.h`,
+    which is still considered to be in alpha stage.
+
+  - TrueType interpreter version 38  (also known as 'Infinality') that
+    was first introduced about 10 years  ago in FreeType 2.4.11 is now
+    deprecated and slated to be removed in the next version.  TrueType
+    interpreter version 40 has been FreeType's default version for six
+    years now and provides an excellent alternative.  This is the last
+    FreeType     version     with    TT_INTERPRETER_VERSION_38     and
+    TT_INTERPRETER_VERSION_40 treated differently.
+
+  - The  only  referenced  but never  documented  configuration  macro
+    `FT_CONFIG_OPTION_NO_GLYPH_NAMES` has been removed.
+
+  - The `ftbench` demo  program got a new command line  option `-e` to
+    set a charmap index.
+
+  - Specifying  a point  size is  now optional  for the  demo programs
+    `ftgrid`, `ftmulti`,  `ftstring`, and  `ftview`.  If not  given, a
+    default size is used.
+
+  - For  `ftgrid`,  `ftstring`, and  `ftview`,  option  `-e` now  also
+    accepts a numeric value to set a charmap index.
+
+  - In  `ftstring`, it  is  now  possible to  set  the displayed  text
+    interactively by pressing the 'Enter' key.
+
+  - `ftmulti` can now handle up to 16 design axes.
+
+  - To  avoid  reserved identifiers  that  are  globally defined,  the
+    auto-hinter  debugging   macros  (which  are  only   available  if
+    `FT_DEBUG_AUTOFIT` is defined)
+
+    ```
+    _af_debug_disable_horz_hints
+    _af_debug_disable_vert_hints
+    _af_debug_disable_blue_hints
+    _af_debug_hints
+    ```
+
+    have been renamed to
+
+    ```
+    af_debug_disable_horz_hints_
+    af_debug_disable_vert_hints_
+    af_debug_disable_blue_hints_
+    af_debug_hints_
+    ```
+
+  - The internal  zlib library was  updated to version  1.2.13.  Note,
+    however, that  FreeType is *not* affected  by CVE-2022-37434 since
+    it doesn't use the `inflateGetHeader` function.
+
+
+======================================================================
+
+CHANGES BETWEEN 2.12.0 and 2.12.1 (2022-May-01)
+
+  I. IMPORTANT BUG FIXES
+
+  - Loading CFF fonts sometimes made FreeType crash (bug introduced in
+    version 2.12.0)
+
+  - Loading  a fully  hinted  TrueType glyph  a  second time  (without
+    caching) sometimes yielded different rendering results if TrueType
+    hinting was active (bug introduced in version 2.12.0).
+
+  - The generation of the pkg-config file `freetype2.pc` was broken if
+    the build was done with cmake (bug introduced in version 2.12.0).
+
+
+  II. MISCELLANEOUS
+
+  - New option `--with-librsvg` for  the `configure` script for better
+    FreeType demo support.
+
+  - The  meson  build  no  longer enforces  both  static  and  dynamic
+    versions of the library by default.
+
+  - The internal  zlib library was  updated to version  1.2.12.  Note,
+    however, that  FreeType is *not* affected  by CVE-2018-25032 since
+    it only does decompression.
+
+
+======================================================================
+
+CHANGES BETWEEN 2.11.1 and 2.12.0 (2022-Mar-30)
+
+  I. IMPORTANT CHANGES
+
+  - FreeType  now   handles  OT-SVG  fonts,  to   be  controlled  with
+    `FT_CONFIG_OPTION_SVG`  configuration macro.   By default,  it can
+    only load the 'SVG ' table of an OpenType font.  However, by using
+    the `svg-hooks` property of the new 'ot-svg' module it is possible
+    to register an  external SVG rendering engine.   The FreeType demo
+    programs  have been  set  up  to use  'librsvg'  as the  rendering
+    library.
+
+    This work was Moazin Khatti's GSoC 2019 project.
+
+
+  II. MISCELLANEOUS
+
+  - The handling of fonts with an 'sbix' table has been improved.
+
+    - Corrected bitmap offsets.
+
+    - A  new tag  `FT_PARAM_TAG_IGNORE_SBIX` for  `FT_Open_Face` makes
+      FreeType ignore an 'sbix' table in a font, allowing applications
+      to access the font's outline glyphs.
+
+    - `FT_FACE_FLAG_SBIX`  and   `FT_FACE_FLAG_SBIX_OVERLAY`  together
+      with their  corresponding preprocessor macros  `FT_HAS_SBIX` and
+      `FT_HAS_SBIX_OVERLAY` enable applications to treat 'sbix' tables
+      as described in the OpenType specification.
+
+  - The internal 'zlib'  code has been updated to be  in sync with the
+    current 'zlib' version (1.2.11).
+
+  - The  previously internal  load  flag  `FT_LOAD_SBITS_ONLY` is  now
+    public.
+
+  - Some  minor improvements  of the  building systems,  in particular
+    handling of the 'zlib' library (internal vs. external).
+
+  - Support for non-desktop Universal Windows Platform.
+
+  - Various other minor bug and documentation fixes.
+
+  - The `ftdump` demo  program shows more information  for Type1 fonts
+    if option `-n` is given.
+
+  - `ftgrid` can now display embedded bitmap strikes.
+
+
+======================================================================
+
+CHANGES BETWEEN 2.11.0 and 2.11.1 (2021-Dec-01)
+
+  I. IMPORTANT CHANGES
+
+    - Some  fields  in  the  `CID_FaceDictRec`, `CID_FaceInfoRec`, and
+      `FT_Data` structures  have been changed  from signed to unsigned
+      type,  which  better reflects  the actual usage.  It is also  an
+      additional means to protect against malformed input.
+
+
+  II. MISCELLANEOUS
+
+    - Cmake support  has been  further improved.   To do  that various
+      backward-incompatible  changes were  necessary; please  see file
+      `CMakeLists.txt` for more details.
+
+    - Since version  2.11.0, a  C99 compiler  is necessary  to compile
+      FreeType.
+
+    - The experimental  'COLR' v1 API  has been updated to  the latest
+      OpenType standard 1.9.
+
+    - The `apinames` tool got a new  option `-wV` to output an OpenVMS
+      Linker Option File.
+
+    - VMS support was updated.
+
+    - MS Visual Studio support was added to build the demo programs.
+
+
+======================================================================
+
+CHANGES BETWEEN 2.10.4 and 2.11.0 (2021-Jul-18)
+
+  I. IMPORTANT CHANGES
+
+  - A  new rendering  module has  been  added to  create 8-bit  Signed
+    Distance Field (SDF)  bitmaps for both outline  and bitmap glyphs.
+    The new  rendering mode is called  `FT_RENDER_MODE_SDF`, the pixel
+    mode is  `FT_PIXEL_MODE_GRAY8`, and the corresponding  raster flag
+    is `FT_RASTER_FLAG_SDF`.
+
+    This work was Anuj Verma's GSoC 2020 project.
+
+  - A new, experimental API is  now available for surfacing properties
+    of 'COLR' v1  color fonts (as the name says,  this is an extension
+    to  the  'COLR' table  for  outline  color  fonts using  the  SFNT
+    container  format).   'COLR'  v1  fonts are  a  recently  proposed
+    addition to OFF and OpenType; specification work currently happens
+    in
+
+      https://github.com/googlefonts/colr-gradients-spec/
+
+    'COLR'  v1  is  expected  to   be  merged  to  OpenType;  the  ISO
+    standardisation process  for adding 'COLR'  v1 as an  amendment to
+    OFF is underway.
+
+    Functions similar  to the  already existing  'COLR' API  have been
+    added to access the corresponding data.
+
+      FT_Get_Color_Glyph_Paint
+        Retrieve the root paint for a given glyph ID.
+
+      FT_Get_Paint_Layers
+        Access the layers of a `PaintColrLayers` table.
+
+      FT_Get_Colorline_Stops
+        Retrieve the  'color stops' on a  color line.  As an  input, a
+        color stop iterator gets used, which in turn is retrieved from
+        a paint.
+
+      FT_Get_Paint
+        Dereference  an  `FT_OpaquePaint`   object  and  retrieve  the
+        corresponding `FT_COLR_Paint`  object, which  contains details
+        on how to draw the respective 'COLR' v1 `Paint` table.
+
+
+  II. MISCELLANEOUS
+
+  - FreeType has moved its infrastructure to
+
+      https://gitlab.freedesktop.org/freetype
+
+    A  side  effect  is  that  the git  repositories  are  now  called
+    `freetype.git` and  `freetype-demos.git`, which by  default expand
+    to the directories  `freetype` and `freetype-demos`, respectively.
+    The documentation has been updated accordingly.
+
+    FreeType's Savannah  repositories will stay; they  are now mirrors
+    of the 'freedesktop.org' repositories.
+
+  - A  new  function  `FT_Get_Transform`  returns  the  values set  by
+    `FT_Set_Transform`.
+
+  - A  new configuration  macro `FT_DEBUG_LOGGING`  is available.   It
+    provides extended debugging capabilities for FreeType, for example
+    showing a time stamp or displaying the component a tracing message
+    comes from.  See file `docs/DEBUG` for more information.
+
+    This work was Priyesh Kumar's GSoC 2020 project.
+
+  - The legacy Type 1 and CFF  engines are further demoted due to lack
+    of CFF2 charstring support.  You now need to use `FT_Property_Set`
+    to  enable  them  besides  the  `T1_CONFIG_OPTION_OLD_ENGINE`  and
+    `CFF_CONFIG_OPTION_OLD_ENGINE` options, respectively.
+
+  - The experimental 'warp' mode (AF_CONFIG_OPTION_USE_WARPER) for the
+    auto-hinter has been removed.
+
+  - The smooth rasterizer performance has been improved by >10%.  Note
+    that  due to  necessary code  changes there  might be  very subtle
+    differences  in  rendering.  They  are  not  visible by  the  eye,
+    however.
+
+  - PCF bitmap fonts compressed with LZW (these are usually files with
+    the extension `.pcf.Z`) are now handled correctly.
+
+  - Improved  Meson  build  files,  including  support  to  build  the
+    FreeType demo programs.
+
+  - A new demo program `ftsdf` is available to display Signed Distance
+    Fields of glyphs.
+
+  - The `ftlint` demo program has been  extended to do more testing of
+    its input.  In particular, it  can display horizontal and vertical
+    acutances  for quality  assessment,  together  with computing  MD5
+    checksums of rendered glyphs.
+
+    [The acutance measures  how sharply the pixel  coverage changes at
+     glyph edges.  For monochrome bitmaps,  it is always 2.0 in either
+     X or  Y direction.  For  anti-aliased bitmaps, it depends  on the
+     hinting and the shape of a glyph and might approach or even reach
+     value 2.0  for glyphs like 'I',  'L', '+', '-', or  '=', while it
+     might be lower for glyphs like 'O', 'S', or 'W'.]
+
+  - The `ttdebug`  demo program didn't show  changed point coordinates
+    (bug introduced in version 2.10.3).
+
+  - It is now possible to adjust the axis increment for variable fonts
+    in the `ftmulti` demo program.
+
+  - It is now possible to change  the hinting engine in the `ftstring`
+    demo program.
+
+  - The graphical demo programs work  better now in native color depth
+    on win32 and x11.
+
+
+======================================================================
+
+CHANGES BETWEEN 2.10.3 and 2.10.4 (2020-Oct-20)
+
+  I. IMPORTANT BUG FIXES
+
+  - A heap buffer overflow has been found  in the handling of embedded
+    PNG bitmaps, introduced in FreeType version 2.6.
+
+      https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-15999
+
+    If you  use option  FT_CONFIG_OPTION_USE_PNG  you  should  upgrade
+    immediately.
+
+
+======================================================================
+
+CHANGES BETWEEN 2.10.2 and 2.10.3 (2020-Oct-10)
+
+  I. IMPORTANT CHANGES
+
+  - New flag `FT_OUTLINE_OVERLAP'.  If set, make the smooth rasterizer
+    do  4x4 oversampling  to  mitigate artifacts  in pixels  partially
+    covered  by  overlapping  contours.    Note  that  this  at  least
+    quadruples the rendering time.
+
+    If  a  glyph  in  a  TrueType font  has  the  `OVERLAP_SIMPLE'  or
+    `OVERLAP_COMPOUND'  bit set,  FreeType automatically  selects this
+    rendering mode.
+
+
+  II. MISCELLANEOUS
+
+  - Using the  arcane method of  including FreeType header  files with
+    macros like  `FT_FREETYPE_H' is no longer  mandatory (but retained
+    as an optional feature for backward compatibility).
+
+  - Support for  building the library  with Meson.  Building  the demo
+    programs with Meson will follow in a forthcoming release.
+
+  - Minor improvements to the B/W rasterizer.
+
+  - Auto-hinter support for Medefaidrin script.
+
+  - Fix various  memory leaks (mainly  for CFF) and other  issues that
+    might cause crashes in rare circumstances.
+
+  - Jam support has been removed.
+
+  - In  `ftview', custom  LCD  filter values  are  now normalized  and
+    balanced.  Unorthodox filters are still available through the `-L'
+    command line option.
+
+  - The GUI demo programs can now be resized.
+
+  - Demo programs that accept command  line option `-k' can now handle
+    function keys, too.  The  corresponding character codes start with
+    0xF1.  As  an example, the  POSIX shell syntax (accepted  by bash,
+    ksh, and zsh)
+
+      -k $'\xF3q'
+
+    emulates the pressing of function key `F3' followed by key `q'.
+
+
+======================================================================
+
+CHANGES BETWEEN 2.10.1 and 2.10.2 (2020-May-09)
+
+  I. IMPORTANT CHANGES
+
+  - Support  of  WOFF2  fonts.   This  code  contribution  was  Nikhil
+    Ramakrishnan's GSoC 2019 project.
+
+
+  II. MISCELLANEOUS
+
+  - Function  `FT_Get_Var_Axis_Flags' returned random data for  Type 1
+    MM fonts.
+
+  - Type 1 fonts with non-integer metrics are now supported by the new
+    (CFF) engine introduced in FreeType 2.9.
+
+  - Drop  support  for Python 2 in Freetype's API reference  generator
+    `docwriter'  (Python >= 3.5 is required for targets  `make refdoc'
+    and `make refdoc-venv').
+
+  - Auto-hinter support for Hanifi Rohingya.
+
+  - Document the `FT2_KEEP_ALIVE' debugging environment variable.
+
+  - The Visual C++ (and Visual C)  project files for Windows builds no
+    longer generate libraries that contain the FreeType version in its
+    filenames.   Instead,  a  resource  file gets  used  to  make  the
+    libraries contain the corresponding information.
+
+  - The next release will remove Jam build support.
+
+  - The  `ftbench'  demo  program  has  a new  test  for  testing  the
+    `FT_Glyph_Stroke' functionality.
+
+
+======================================================================
+
+CHANGES BETWEEN 2.10.0 and 2.10.1 (2019-Jul-01)
+
+  I. IMPORTANT BUG FIXES
+
+  - The bytecode hinting of OpenType variation fonts was flawed, since
+    the data in the `CVAR' table wasn't correctly applied.
+
+
+  II. MISCELLANEOUS
+
+  - Auto-hinter support for Mongolian.
+
+  - For distribution,  `.tar.bz2' packages are replaced with `.tar.xz'
+    bundles.
+
+  - The handling of  the default character in PCF fonts as  introduced
+    in version 2.10.0 was partially broken, causing premature abortion
+    of charmap iteration for many fonts.
+
+  - If  `FT_Set_Named_Instance' was  called  with  the same  arguments
+    twice in a row, the function  returned an incorrect error code the
+    second time.
+
+  - Direct   rendering   using  FT_RASTER_FLAG_DIRECT   crashed   (bug
+    introduced in version 2.10.0).
+
+  - Increased  precision  while  computing  OpenType  font   variation
+    instances.
+
+  - The  flattening  algorithm of  cubic  Bezier  curves was  slightly
+    changed to make  it faster.  This can cause  very subtle rendering
+    changes, which aren't noticeable by the eye, however.
+
+  - The  auto-hinter  now  disables hinting  if there  are blue  zones
+    defined for a `style' (i.e., a certain combination of a script and
+    its related typographic features) but the font doesn't contain any
+    characters needed to set up at least one blue zone.
+
+  - The `ftmulti' demo program now  supports multiple hidden axes with
+    the same name tag.
+
+  - `ftview', `ftstring', and `ftgrid' got  a `-k' command line option
+    to emulate a sequence of keystrokes at start-up.
+
+  - `ftview', `ftstring', and `ftgrid' now support screen dumping to a
+    PNG file.
+
+  - The bytecode debugger, `ttdebug',  now supports variation TrueType
+    fonts; a variation font instance can be selected with the new `-d'
+    command line option.
+
+
+======================================================================
+
+CHANGES BETWEEN 2.9.1 and 2.10.0 (2019-Mar-15)
+
+  I. IMPORTANT CHANGES
+
+    - A bunch  of new functions has  been added to access  and process
+      COLR/CPAL data of OpenType fonts with color-layered glyphs.
+
+        FT_Palette_Data_Get
+          Retrieve color palette data.
+        FT_Palette_Select
+          Select and activate a color palette for color-layered
+          glyphs.
+        FT_Palette_Set_Foreground_Color
+          Set text foreground color for palette index 0xFFFF.
+
+        FT_Get_Color_Glyph_Layer
+          Get color layers for a given glyph (using an interator
+          object).
+
+        FT_Bitmap_Blend
+          Blend one bitmap onto another with a given color.
+
+    - An   experimental  feature   is   the  new   behaviour  of   the
+      `FT_LOAD_COLOR' load  flag for color-layered  glyphs: Internally
+      it  sets a  flag so  that  if `FT_Render_Glyph'  is called  with
+      `FT_RENDER_MODE_NORMAL'      (or       `FT_Load_Glyph'      with
+      `FT_LOAD_RENDER'), a default blending  of the color glyph layers
+      will happen automatically for convenience.
+
+    - As  a   GSoC  2018   project,  Nikhil   Ramakrishnan  completely
+      overhauled and modernized the API reference.
+
+
+  II. MISCELLANEOUS
+
+    - The  logic for  computing  the global  ascender, descender,  and
+      height  of  OpenType  fonts   has  been  slightly  adjusted  for
+      consistency.
+
+      . If the `useTypoMetrics' flag (i.e., bit 7 in the `fsSelection'
+        field) in the  `OS/2' table is set, use the  `sTypo' fields in
+        `OS/2' unconditionally.
+      . Otherwise use  the metrics data from the `hhea'  table (if not
+        zero).
+      . Otherwise use the `sTypo' fields from the `OS/2' table (if not
+        zero).
+      . Otherwise use the `usWin' data from the `OS/2' table as a last
+        resort.
+
+      Variable fonts will apply the `MVAR' deltas to whichever metrics
+      were picked.
+
+    - `TT_Set_MM_Blend' could  fail if  call repeatedly with  the same
+      arguments.
+
+    - The precision  of handling  deltas in  Variation Fonts  has been
+      increased.  The  problem did only show  up with multidimensional
+      designspaces.
+
+    - New function `FT_Library_SetLcdGeometry' to  set up the geometry
+      of LCD subpixels.
+
+    - FreeType now uses the `defaultChar' property of PCF fonts to set
+      the  glyph for  the undefined  character  at glyph  index 0  (as
+      FreeType already does for all other supported font formats).  As
+      a consequence,  the order of  glyphs of  a PCF font  if accessed
+      with  FreeType  can  be   different  now  compared  to  previous
+      versions.
+
+      This change doesn't affect PCF font access with cmaps.
+
+    - `FT_Select_Charmap' has  been changed  to allow  parameter value
+      `FT_ENCODING_NONE', which is valid for BDF, PCF, and Windows FNT
+      formats to  access built-in cmaps  that don't have  a predefined
+      `FT_Encoding' value.
+
+    - A previously  reserved field in the  `FT_GlyphSlotRec' structure
+      now holds the glyph index.
+
+    - On Win32 platforms,  the use of `_DLL' to build  the library has
+      been replaced with `DLL_EXPORT' and `DLL_IMPORT'.
+
+    - The usual round  of fuzzer bug fixes to  better reject malformed
+      fonts.
+
+    - `FT_Outline_New_Internal'  and  `FT_Outline_Done_Internal'  have
+      been removed.  These two functions were public by oversight only
+      and were never documented.
+
+    - A new  function `FT_Error_String' returns descriptions  of error
+      codes if  configuration macro  FT_CONFIG_OPTION_ERROR_STRINGS is
+      defined.
+
+    - `FT_Set_MM_WeightVector'  and  `FT_Get_MM_WeightVector' are  new
+      functions limited to Adobe MultiMaster fonts to directly set and
+      get the weight vector.
+
+    - Support for Position Independent Code as needed by  systems that
+      prohibit  automatic  address  fixups,  such  as BREW,  has  been
+      removed.  [Compilation with modern compilers that use flags like
+      `-fPIC' or `-fPIE' is not affected.]
+
+    - The  `ftdump' demo  program has  new  options `-c'  and `-C'  to
+      display charmaps  in compact and detailed  format, respectively.
+      Option `-V' has been removed.
+
+    - The `ftview', `ftstring',  and `ftgrid' demo programs  use a new
+      command line option `-d' to  specify the program window's width,
+      height, and color depth.
+
+    - The `ftview' demo program now  displays red boxes for zero-width
+      glyphs.
+
+    - `ftglyph'   has   limited   support  to   display   fonts   with
+      color-layered glyphs.  This will be improved later on.
+
+    - `ftgrid' can now display bitmap fonts also.
+
+    - The `ttdebug'  demo program has  a new  option `-f' to  select a
+      member of a TrueType collection (TTC).
+
+    - Other various improvements to the demo programs.
+
+
+======================================================================
+
+CHANGES BETWEEN 2.9 and 2.9.1 (2019-May-01)
+
+  I. IMPORTANT BUG FIXES
+
+    - Type  1  fonts  containing   flex  features  were  not  rendered
+      correctly (bug introduced in version 2.9).
+
+    - CVE-2018-6942: Older  FreeType versions  can crash  with certain
+      malformed variation fonts.
+
+        https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-6942
+
+
+  II. MISCELLANEOUS
+
+    - Bug fix: Multiple calls to `FT_Get_MM_Var' returned garbage.
+
+    - The base  extensions `ftlcdfil' and  `ftfntfmt' are now  part of
+      the  base  module  (and  thus no  longer  configurable  in  file
+      `modules.cfg').
+
+    - Emboldening of bitmaps didn't work correctly sometimes,  showing
+      various artifacts (bug introduced in version 2.8.1).
+
+    - Use  of  the `freetype-config'  script  to  get compilation  and
+      linking  options   is  deprecated   since  it   doesn't  support
+      cross-compiling, among other  deficiencies.  Instead, you should
+      use the `pkg-config' interface.
+
+      The `configure'  script no longer installs  `freetype-config' by
+      default.  For  backward  compatibility,  a new  configure option
+      `--enable-freetype-config'   is  provided   that  reverts   this
+      decision.
+
+    - The auto-hinter script ranges have  been updated for Unicode 11.
+      No support  for new scripts  have been added, however,  with the
+      exception of Georgian Mtavruli.
+
+    - Support for cmake has been improved.
+
+    - The next  release will  remove support for  Position Independent
+      Code  as  needed  by  systems that  prohibit  automatic  address
+      fixups, such  as BREW.  [Compilation with  modern compilers that
+      use flags like `-fPIC' or `-fPIE' is not affected.]
+
+
+======================================================================
+
+CHANGES BETWEEN 2.8.1 and 2.9 (2018-Jan-08)
+
+  I. IMPORTANT BUG FIXES
+
+    - Advance width values of variation fonts were often wrong.
+
+    - More fixes for variation font support; you should update to this
+      version if you want to support them.
+
+
+  II. IMPORTANT CHANGES
+
+    - As a GSoC project, Ewald Hew extended the new (Adobe) CFF engine
+      to  handle  Type  1  fonts  also,  thus  greatly  improving  the
+      rendering of  this format.   This is the  new default.   The old
+      engine   is  still   available   if   the  configuration   macro
+      `T1_CONFIG_OPTION_OLD_ENGINE'    gets    defined;   using    the
+      `hinting-engine' property  of the `type1' driver  module you can
+      then switch between the two engines.
+
+    - A new function,  `FT_Set_Named_Instance', can be used  to set or
+      change the current named instance.
+
+    - Starting  with   this  FreeType  version,   resetting  variation
+      coordinates  will   return  to  the  currently   selected  named
+      instance.  Previously, FreeType returned to the base font (i.e.,
+      no instance set).
+
+
+  III. MISCELLANEOUS
+
+    - The `face_flags' field of the `FT_Face' structure has a new bit,
+      `FT_FACE_FLAG_VARIATION', which  is set if a  variation font has
+      been      altered      with      `FT_Set_MM_Design_Coordinates',
+      `FT_Set_Var_Design_Coordinates',                              or
+      `FT_Set_Var_Blend_Coordinates'.
+
+    - If  the  current  face  is  a  named  instance,  the  new  macro
+      `FT_IS_NAMED_INSTANCE' returns true.
+
+    - `FT_IS_VARIATION' is  a new macro  that returns true  whenever a
+      face object has  been altered by `FT_Set_MM_Design_Coordinates',
+      `FT_Set_Var_Design_Coordinates',                              or
+      `FT_Set_Var_Blend_Coordinates'.
+
+    - Changing  the  design  coordinates  of  a  variation  font  with
+      `FT_Set_Var_Design_Coordinates'                               or
+      `FT_Set_Var_Blend_Coordinates'  does  not  influence  the  named
+      instance index value (only `FT_Set_Named_Instance' does that).
+
+    - Special PostScript  names for named instances  are only returned
+      if the  named instance is set  with `FT_Set_Named_Instance' (and
+      the font  has corresponding  entries in  its `fvar'  table).  If
+      `FT_IS_VARIATION'  returns  true,  the  algorithmically  derived
+      PostScript name is provided, not  looking up special entries for
+      named instances.
+
+    - A new function  `FT_Done_MM_Var' is provided to  free the memory
+      returned in a call to `FT_Get_MM_Var'.
+
+    - On  platforms  using  the   `configure'  script,  the  installed
+      `ftoption.h' file  now correctly reflects  configuration options
+      like `--with-harfbuzz'.
+
+    - Better  support to  build FreeType  as  a DLL  on Windows  using
+      Visual C.
+
+    - All data specific to driver modules is now collected in a single
+      file,      `FT_DRIVER_H'.      Consequently,      the     macros
+      `FT_AUTOHINTER_H',   `FT_CFF_DRIVER_H',  `FT_TRUETYPE_DRIVER_H',
+      and `FT_PCF_DRIVER_H' still work but are deprecated.
+
+    - Some fuzzer fixes to better reject malformed fonts.
+
+    - The `ftbench' demo program has a new test for opening a new face
+      and loading some glyphs.
+
+    - The `ftbench' demo program has a  new option `-j' to specify the
+      last glyph index to be used in the tests.
+
+    - The  `ftgrid' demo  program has  a new  option `-n'  to suppress
+      display of named instances of variation fonts.
+
+    - The `ttdebug' demo program can now  show a stack trace (key `K')
+      and switch  between hexadecimal and decimal  display of integers
+      (key `I').
+
+
+======================================================================
+
+CHANGES BETWEEN 2.8 and 2.8.1 (2017-Sep-16)
+
+  I. IMPORTANT BUG FIXES
+
+    - B/W  hinting   of  TrueType   fonts  didn't  work   properly  if
+      interpreter version 38 or 40 was selected.
+
+    - Some severe  problems within the handling  of TrueType Variation
+      Fonts were found and fixed.
+
+    - Function `FT_Set_Var_Design_Coordinates' didn't correctly handle
+      the case with less input coordinates than axes.
+
+
+  II. IMPORTANT CHANGES
+
+    - By  default,  FreeType  now offers  high  quality  LCD-optimized
+      output without  resorting to ClearType techniques  of resolution
+      tripling and  filtering.  In  this method, called  Harmony, each
+      color channel  is generated separately after  shifting the glyph
+      outline, capitalizing  on the fact  that the color grids  on LCD
+      panels  are shifted  by  a third  of a  pixel.   This output  is
+      indistinguishable from ClearType with a light 3-tap filter.
+
+
+  III. MISCELLANEOUS
+
+    - Using the  new function `FT_Get_Var_Axis_Flags',  an application
+      can access the `flags' field  of a variation axis (introduced in
+      OpenType version 1.8.2)
+
+    - More sanity checks.
+
+    - The  internal representation  of buffers  for LCD  rendering has
+      changed (to be more precise, the amount of padding gets computed
+      differently).  Applications  that use  the FreeType API  are not
+      affected.
+
+    - To  reset all  design axis  values of  a variation  font to  its
+      default values you can now say
+
+        error = FT_Set_Var_Design_Coordinates( face, 0, NULL );
+
+      This  also works  with functions  `FT_Set_MM_Design_Coordinates'
+      and `FT_Set_MM_Blend_Coordinates'.
+
+    - FreeType  now synthesizes  a  missing Unicode  cmap for  (older)
+      TrueType fonts also if glyph names are available.
+
+    - FreeType  has  improved  handling   of  BDF  fonts  without  the
+      `POINT_SIZE', `RESOLUTION_X', or  `RESOLUTION_Y' properties; the
+      library now  uses the values of  the `SIZE' keyword if  they are
+      missing.   Previously,   `SIZE'  was  completely   ignored,  and
+      FreeType used heuristic values instead.
+
+    - Multiple calls to `FT_Bitmap_Convert' do work now as advertised.
+      Previously,  they failed with an assertion error if there was an
+      empty bitmap between non-empty ones.
+
+    - The warping option  has moved  from `light'  to `normal' hinting
+      where  it replaces  the original hinting algorithm.  The `light'
+      mode is now always void of any hinting in x-direction.
+
+    - 16bit  compiler  support is  now  officially  ended.  We  didn't
+      provide any maintenance  since many years,  and given that there
+      were no error  or problem reports either it seems  that it is no
+      longer needed.
+
+    - The `ftgrid'  demo program  can now toggle  the display  of grid
+      lines with the `G' key.
+
+    - The `ftgrid' demo  program can toggle a different  set of colors
+      (suitable to color-blind people) with the `C' key.
+
+    - The `ftgrid'  demo program  now supports  the `-e'  command line
+      option to select a cmap.
+
+    - The `ftdump' demo program has a  new command line option `-t' to
+      output the SFNT table list.
+
+
+======================================================================
+
+CHANGES BETWEEN 2.7.1 and 2.8 (2017-May-13)
+
+  I. IMPORTANT CHANGES
+
+    - Support for OpenType Variation Fonts is now complete.   The last
+      missing part was handling the `VVAR' and `MVAR' tables, which is
+      available with this release.
+
+    - A new  function `FT_Face_Properties' allows the  control of some
+      module  and   library  properties  per  font.    Currently,  the
+      following properties can be  handled: stem darkening, LCD filter
+      weights, and the random seed for the `random' CFF operator.
+
+    - The PCF change to show more `colorful'  family names (introduced
+      in version 2.7.1) was too radical; it can now be configured with
+      PCF_CONFIG_OPTION_LONG_FAMILY_NAMES   at   compile   time.    If
+      activated, it can  be switched off at run time  with the new pcf
+      property  `no-long-family-names'.  If  the `FREETYPE_PROPERTIES'
+      environment variable is available, you can say
+
+        FREETYPE_PROPERTIES=pcf:no-long-family-names=1
+
+    - Support  for  the  following  scripts  has  been  added  to  the
+      auto-hinter.
+
+        Adlam, Avestan, Bamum, Buhid, Carian, Chakma, Coptic, Cypriot,
+        Deseret, Glagolitic, Gothic, Kayah, Lisu, N'Ko, Ol Chiki, Old
+        Turkic, Osage, Osmanya, Saurashtra, Shavian, Sundanese, Tai
+        Viet, Tifinagh, Unified Canadian Syllabics, Vai
+
+
+  II. IMPORTANT BUG FIXES
+
+    - `Light' auto-hinting  mode no  longer uses TrueType  metrics for
+      TrueType  fonts.   This bug  was  introduced  in version  2.4.6,
+      causing   horizontal  scaling   also.    Almost  all   GNU/Linux
+      distributions (with Fedora as  a notable exception) disabled the
+      corresponding patch for good reasons; chances are thus high that
+      you won't notice a difference.
+
+      If  optical backward  compatibility for  legacy applications  is
+      necessary, you might enable the AF_CONFIG_OPTION_TT_SIZE_METRICS
+      configuration option.   However, it  is strongly  recommended to
+      avoid that, adjusting font sizes instead.
+
+    - Global size  metrics values  in the  `FT_Size_Metrics' structure
+      can be  different for TrueType  fonts.  Reason is that  in older
+      FreeType  versions  the  metrics  were  rounded  differently  to
+      integer pixels compared  to all other font  formats, yielding an
+      inconsistent behaviour if you used non-native hinting.  Starting
+      with this  version, global size  metrics for TrueType  fonts are
+      handled the same as other  font formats: `ascender' gets rounded
+      up,  `descender'  gets  rounded  down,  `height'  gets  normally
+      rounded, and `max_advance' gets normally rounded, too.
+
+      If you need more precise values of (global) ascender, descender,
+      height, or  `max_advance', please take the  corresponding values
+      from the `FT_Face' structure and scale them manually.
+
+    - If a TrueType font gets loaded with FT_LOAD_NO_HINTING, FreeType
+      now scales  the font linearly  again (bug introduced  in version
+      2.4.6).
+
+    - CVE-2017-8105,  CVE-2017-8287:  Older   FreeType  versions  have
+      out-of-bounds  writes  caused  by  heap-based  buffer  overflows
+      related to Type 1 fonts.
+
+        https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-8105
+        https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-8287
+
+
+  III. MISCELLANEOUS
+
+    - A  new function  `FT_Set_Default_Properties' has  been added  to
+      parse    the    `FREETYPE_PROPERTIES'    environment    variable
+      (previously, it  was internal only).   `FT_Init_FreeType' always
+      call this  function, but  `FT_New_Library' does not  (similar to
+      `FT_Add_Default_Modules').
+
+    - To be in sync with OpenType version 1.7 and newer, macros
+
+        FT_PARAM_TAG_IGNORE_PREFERRED_FAMILY,
+        FT_PARAM_TAG_IGNORE_PREFERRED_SUBFAMILY,
+        TT_NAME_ID_PREFERRED_FAMILY
+        TT_NAME_ID_PREFERRED_SUBFAMILY
+
+      are renamed to
+
+        FT_PARAM_TAG_IGNORE_TYPOGRAPHIC_FAMILY,
+        FT_PARAM_TAG_IGNORE_TYPOGRAPHIC_SUBFAMILY,
+        TT_NAME_ID_TYPOGRAPHIC_FAMILY
+        TT_NAME_ID_TYPOGRAPHIC_SUBFAMILY
+
+      The old macro names are deprecated (but still available).
+
+    - Support for SFNT `name' tables has been improved.
+
+      . Format  1 `name' tables  are now supported.  Use  new function
+        `FT_Get_Sfnt_LangTag' to access associated language tags.
+
+      . Language, encoding, and name IDs have been updated to OpenType
+        version 1.8.1.
+
+    - The new CFF  engine now handles the `random'  operator.  All CFF
+      opcodes are now supported.
+
+    - The CFF module  has a new property `random-seed'  to control the
+      pseudo-random number generation for the `random' operator.
+
+    - The `freetype-config' script is now a wrapper of `pkg-config' if
+      this program is available in the path.
+
+    - FT_LOAD_TARGET_LCD  is now  a  variant of  FT_LOAD_TARGET_LIGHT;
+      this should provide better rendering results.
+
+    - A mode to display  light auto-hinting with  subpixel positioning
+      has been added to `ftdiff'.
+
+
+======================================================================
+
+CHANGES BETWEEN 2.7 and 2.7.1 (2016-Dec-30)
+
+  I. IMPORTANT CHANGES
+
+    - Support for the new CFF2 font format as introduced with OpenType
+      1.8 has been contributed by Dave Arnolds from Adobe.
+
+    - Preliminary support for variation fonts as specified in OpenType
+      1.8 (in addition to the  already existing support for Adobe's MM
+      and Apple's  GX formats).  Dave Arnolds  contributed handling of
+      advance  width change  variation;  more will  come  in the  next
+      version.
+
+
+  II. IMPORTANT BUG FIXES
+
+    - Handling of  raw CID fonts was partially  broken (bug introduced
+      in 2.6.4).
+
+    - CVE-2016-10328:  Older  FreeType versions had  an  out-of-bounds
+      write caused by a heap-based  buffer overflow related to the CFF
+      fonts.
+
+        https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-10328
+
+
+  III. MISCELLANEOUS
+
+    - Some limits for TrueType  bytecode execution have been tightened
+      to  speed   up  FreeType's  handling  of   malformed  fonts,  in
+      particular to quickly abort endless loops.
+
+      - The  number of  twilight points  can no  longer be  set to  an
+        arbitrarily large value.
+
+      - The total number of jump  opcode instructions (like JMPR) with
+        negative arguments  is dynamically restricted; the  same holds
+        for the total number of iterations in LOOPCALL opcodes.
+
+      The dynamic limits are based on  the number of points in a glyph
+      and the number of CVT entries.  Please report if you encounter a
+      font where the selected values are not adequate.
+
+    - PCF family names are made more `colorful';  they now include the
+      foundry  and information  whether they contain  wide characters.
+      For example,  you no longer get `Fixed' but  rather `Sony Fixed'
+      or `Misc Fixed Wide'.
+
+    - A new  function `FT_Get_Var_Blend_Coordinates'  (with its  alias
+      name  `FT_Get_MM_Blend_Coordinates') to retrieve the  normalized
+      blend  coordinates of the currently  selected variation instance
+      has been added to the Multiple Masters interface.
+
+    - A new  function `FT_Get_Var_Design_Coordinates' to  retrieve the
+      design coordinates of the  currently selected variation instance
+      has been added to the Multiple Masters interface.
+
+    - A new load flag `FT_LOAD_BITMAP_METRICS_ONLY' to retrieve bitmap
+      information without loading the (embedded) bitmap itself.
+
+    - Retrieving   advance   widths   from   bitmap   strikes   (using
+      `FT_Get_Advance' and `FT_Get_Advances') have been sped up.
+
+    - The  usual round  of  fuzzer fixes  to  better reject  malformed
+      fonts.
+
+    - The `ftmulti' demo program can now switch engines with key `H'.
+
+    - The  `ftstring'  demo  program   can  now  show  some  built-in,
+      non-latin sample strings (to be selected with the TAB key).
+
+    - The  `ftview'  demo program  can  now  switch between  a  font's
+      charmaps using the TAB key.
+
+
+======================================================================
+
+CHANGES BETWEEN 2.6.5 and 2.7 (2016-Sep-08)
+
+  I. IMPORTANT CHANGES
+
+    - As announced earlier, the 2.7.x series now uses the new subpixel
+      hinting  mode as  the  default, emulating  a  modern version  of
+      ClearType.
+
+      This change inevitably leads to different rendering results, and
+      you   might   change   the   `TT_CONFIG_OPTION_SUBPIXEL_HINTING'
+      configuration option to  adapt it to your taste (or  use the new
+      `FREETYPE_PROPERTIES'    environment    variable).    See    the
+      corresponding entry  below for  version 2.6.4, which  gives more
+      information.
+
+    - A new option  `FT_CONFIG_OPTION_ENVIRONMENT_PROPERTIES' has been
+      introduced.   If  set (which  is  the  default), an  environment
+      variable  `FREETYPE_PROPERTIES' can  be used  to control  driver
+      properties.  Example:
+
+        FREETYPE_PROPERTIES=truetype:interpreter-version=35 \
+                            cff:no-stem-darkening=1 \
+                            autofitter:warping=1
+
+      This allows to select, say, the subpixel hinting mode at runtime
+      for a given application.  See file `ftoption.h' for more.
+
+
+  II. IMPORTANT BUG FIXES
+
+    - After  loading a  named instance  of  a GX  variation font,  the
+      `face_index'  value  in  the returned  `FT_Face'  structure  now
+      correctly holds the named instance  index in the upper 16bits as
+      documented.
+
+
+  III. MISCELLANEOUS
+
+    - A new macro `FT_IS_NAMED_INSTANCE' to  test whether a given face
+      is a named instance.
+
+    - More fixes to GX font handling.
+
+    - Apple's   `GETVARIATION'  bytecode   operator  (needed   for  GX
+      variation font support) has been implemented.
+
+    - Another round  of fuzzer fixes,  mainly to reject  invalid fonts
+      faster.
+
+    - Handling of raw CID fonts  was broken (bug introduced in version
+      2.6.4).
+
+    - The smooth rasterizer has been streamlined  to make it faster by
+      approx. 20%.
+
+    - The `ftgrid'  demo program now  understands command  line option
+      `-d' to give start-up design coordinates.
+
+    - The `ftdump' demo program has  a new command line option `-p' to
+      dump TrueType bytecode instructions.
+
+
+======================================================================
+
+CHANGES BETWEEN 2.6.4 and 2.6.5 (2016-Jul-12)
+
+  I. IMPORTANT BUG FIXES
+
+    - Compilation works again  on Mac OS X (bug introduced  in version
+      2.6.4).
+
+
+  II. IMPORTANT CHANGES
+
+    - The new  subpixel hinting  mode is now  disabled by  default; it
+      will  be enabled  by default  in the  forthcoming 2.7.x  series.
+      Main reason for reverting this feature is the principle of least
+      surprise: a  sudden change in  appearance of all fonts  (even if
+      the rendering improves  for almost all recent  fonts) should not
+      be expected in a new micro version of a series.
+
+
+======================================================================
+
+CHANGES BETWEEN 2.6.3 and 2.6.4 (2016-Jul-05)
+
+  I. IMPORTANT CHANGES
+
+    - A new  subpixel hinting  mode has  been contributed  by Nikolaus
+      Waxweiler, which is now the  default rendering mode for TrueType
+      fonts.  It implements  (almost everything of) version  40 of the
+      bytecode engine.
+
+      The existing code  base in FreeType (the  `Infinality code') was
+      stripped to the bare minimum  and all configurability removed in
+      the  name  of speed  and  simplicity.   The configurability  was
+      mainly aimed  at legacy  fonts like Arial,  Times New  Roman, or
+      Courier.  [Legacy fonts are fonts  that modify vertical stems to
+      achieve clean black-and-white bitmaps.]  The new mode focuses on
+      applying a minimal set of rules to all fonts indiscriminately so
+      that modern and web fonts  render well while legacy fonts render
+      okay.
+
+      Activation  of the  subpixel hinting  support can  be controlled
+      with   the   `TT_CONFIG_OPTION_SUBPIXEL_HINTING'   configuration
+      option  at compile  time: If  set to  value 1,  you get  the old
+      Infinality  mode  (which  was  never  the  default  due  to  its
+      slowness).  Value 2 activates the new subpixel hinting mode, and
+      value 3 activates both.  The default is value 2.
+
+      At run time,  you can select the subpixel hinting  mode with the
+      `interpreter-version'  property (provided  you have  compiled in
+      the corresponding hinting mode); see `ftttdrv.h' for more.
+
+    - Support  for  the  following  scripts  has  been  added  to  the
+      auto-hinter.
+
+        Armenian, Cherokee, Ethiopic, Georgian, Gujarati, Gurmukhi,
+        Malayalam, Sinhala, Tamil
+
+
+  II. MISCELLANEOUS
+
+    - Type 42 fonts as created by LilyPond are now supported.
+
+    - Minor rendering improvements in the auto-hinter.
+
+    - For experimental  reasons, the old  CFF engine now  supports all
+      CFF operators except `random', including the deprecated Multiple
+      Masters  instructions.  This  allows the  display of  fonts like
+      `ITCGaramondMM-It.otf' (without font variations, though).
+
+    - Another round of fixes to improve handling of invalid fonts.
+
+    - The `ftgrid' demo program now displays the rendered pixels also;
+      this can be switched off with the `b' key.  Selection of various
+      LCD filtering modes can be done with the `L' key.
+
+    - The demo programs  have been extended to allow  selection of all
+      available TrueType bytecode engines.
+
+    - A very early beta version of a new, Qt based demo program called
+      `ftinspect'  is  part  of  the   source  code  bundle;  it  will
+      eventually supersede  the other  demo programs.   Currently, you
+      have to compile  it manually with `qmake; make';  note that many
+      features are still missing.
+
+
+======================================================================
+
+CHANGES BETWEEN 2.6.2 and 2.6.3 (2016-Feb-08)
+
+  I. IMPORTANT CHANGES
+
+    - Khmer,  Myanmar, Bengali,  and Kannada  script support  has been
+      added to the auto-hinter.
+
+
+  II. MISCELLANEOUS
+
+    - Better  support of  Indic  scripts like  Devanagari  by using  a
+      top-to-bottom hinting flow.
+
+    - All  FreeType macros  starting  with two  underscores have  been
+      renamed to  avoid a violation of  both the C and  C++ standards.
+      Example: Header  macros of the  form `__FOO_H__' are  now called
+      `FOO_H_'.  In most cases,  this should be completely transparent
+      to the user.   The exception to this  is `__FTERRORS_H__', which
+      must be  sometimes undefined by  the user to get  FreeType error
+      strings:  Both this  form and  the new  `FTERRORS_H_' macro  are
+      accepted for backward compatibility.
+
+    - Minor improvements mainly to the Type 1 driver.
+
+    - The  new CFF  engine now  supports all  Type 2  operators except
+      `random'.
+
+    - The macro `_STANDALONE_', used for  compiling the B/W and smooth
+      rasterizers  as   stand-alone  modules,  has  been   renamed  to
+      `STANDALONE_', since macro names starting with an underscore and
+      followed by an uppercase letter are reserved in both C and C++.
+
+    - Function  `FT_Library_SetLcdFilterWeights'  now  also  activates
+      custom LCD filter weights (instead of just adjusting them).
+
+    - Support for  `unpatented hinting'  has been  completely removed:
+      Consequently,  the two  functions `FT_Face_CheckTrueTypePatents'
+      and  `FT_Face_SetUnpatentedHinting'  now  return  always  false,
+      doing nothing.
+
+    - The `ftgamma' demo  program has been modernized;  the gamma grid
+      display has been moved from `ftview' to this program.
+
+    - In `ftview',  it is now possible to cycle through  the available
+      LCD filtering modes.
+
+
+======================================================================
+
+CHANGES BETWEEN 2.6.1 and 2.6.2 (2015-Nov-28)
+
+  I. IMPORTANT CHANGES
+
+    - The auto-hinter now supports stem darkening, to be controlled by
+      the    new   `no-stem-darkening'    and   `darkening-parameters'
+      properties.   This is  an  experimental  feature contributed  by
+      Nikolaus Waxweiler, and  the interface might change  in a future
+      release.
+
+    - By default, stem darkening is now switched off (for both the CFF
+      engine and the  auto-hinter).  The main reason is  that you need
+      linear  alpha  blending  and  gamma correction  to  get  correct
+      rendering results, and  the latter is not yet  available in most
+      freely  available  rendering  stacks like  X11.   Applying  stem
+      darkening without proper gamma correction  leads to far too dark
+      rendering results.
+
+    - The   meaning  of   `FT_RENDER_MODE_LIGHT'  has   been  slightly
+      modified.   It  now  essentially  means `no  hinting  along  the
+      horizontal  axis'; in  particular,  no change  of glyph  advance
+      widths.  Consequently, the auto-hinter  is used for all scalable
+      font  formats  except  for  CFF.    It  is  planned  that  other
+      font-specific rendering engines (TrueType, Type 1) will follow.
+
+
+  II. MISCELLANEOUS
+
+    - The default  LCD filter  has been changed  to be  normalized and
+      color-balanced.
+
+    - For    better    compatibility   with    FontConfig,    function
+      `FT_Library_SetLcdFilter'  accepts   a  new   enumeration  value
+      `FT_LCD_FILTER_LEGACY1'   (which  has   the   same  meaning   as
+      `FT_LCD_FILTER_LEGACY').
+
+    - A large number of bugs have been detected by using the libFuzzer
+      framework,  which should  further  improve  handling of  invalid
+      fonts.  Thanks again to Kostya Serebryany and Bungeman!
+
+    - `TT_CONFIG_OPTION_MAX_RUNNABLE_OPCODES',  a   new  configuration
+      option, controls the maximum number of executed opcodes within a
+      bytecode program.  You don't want to change this except for very
+      special  situations (e.g.,  making a  library fuzzer  spend less
+      time to handle broken fonts).
+
+    - The smooth renderer has been made faster.
+
+    - The `ftstring' demo program now supports subpixel rendering; use
+      key `l' to cycle through the LCD modes.
+
+    - The `ftstring'  demo program now supports  color rendering;  use
+      the `space' key to cycle through various color combinations.
+
+    - The graphical demo programs now use a default gamma value of 1.8
+      (instead of 1.2).
+
+
+======================================================================
+
+CHANGES BETWEEN 2.6 and 2.6.1 (2015-Oct-04)
+
+  I. IMPORTANT BUG FIXES
+
+    - It turned  out that for CFFs  only the advance widths  should be
+      taken from the  `htmx' table, not the side  bearings.  This bug,
+      introduced in  version 2.6.0, makes  it necessary to  upgrade if
+      you are using  CFFs; otherwise, you get cropped  glyphs with GUI
+      interfaces like GTK or Qt.
+
+    - Accessing Type 42 fonts returned  incorrect results if the glyph
+      order of the embedded TrueType font differs from the glyph order
+      of the Type 42 charstrings table.
+
+
+  II. IMPORTANT CHANGES
+
+    - The header  file layout  has been  changed (again),  moving  all
+      header files except `ft2build.h' into a subdirectory tree.
+
+      Doing so  reduces the  possibility of  header file  name clashes
+      (e.g., FTGL's  `FTGlyph.h' with FreeType's `ftglyph.h')  on case
+      insensitive file systems like Mac OS X or Windows.
+
+      Applications  that  use  (a)  the  `freetype-config'  script  or
+      FreeType's `freetype2.pc' file for pkg-config to get the include
+      directory  for the  compiler,  and (b)  the  documented way  for
+      header inclusion like
+
+        #include <ft2build.h>
+        #include FT_FREETYPE_H
+        ...
+
+      don't need any change to the source code.
+
+    - Simple access  to named instances  in GX variation fonts  is now
+      available (in addition to the  previous method via FreeType's MM
+      interface).   In  the `FT_Face'  structure,  bits  16-30 of  the
+      `face_index' field hold the current named instance index for the
+      given face  index, and bits  16-30 of `style_flags'  contain the
+      number of  instances for  the given face  index.  `FT_Open_Face'
+      and friends also understand the  extended bits of the face index
+      parameter.
+
+      You need to enable  TT_CONFIG_OPTION_GX_VAR_SUPPORT for this new
+      feature.  Otherwise, bits  16-30 of the two fields  are zero (or
+      are ignored).
+
+    - Lao script support has been added to the auto-hinter.
+
+
+  III. MISCELLANEOUS
+
+    - The auto-hinter's Arabic script support has been enhanced.
+
+    - Superscript-like and  subscript-like glyphs  as used  by various
+      phonetic alphabets like the IPA  are now better supported by the
+      auto-hinter.
+
+    - The TrueType bytecode interpreter now runs slightly faster.
+
+    - Improved support for builds with cmake.
+
+    - The  function  `FT_CeilFix'  now   always  rounds  towards  plus
+      infinity.
+
+    - The  function  `FT_FloorFix'  now always  rounds  towards  minus
+      infinity.
+
+    - A  new load  flag `FT_LOAD_COMPUTE_METRICS'  has been  added; it
+      makes FreeType  ignore pre-computed  metrics, as needed  by font
+      validating  or  font  editing  programs.  Right  now,  only  the
+      TrueType  module supports  it  to ignore  data  from the  `hdmx'
+      table.
+
+    - Another round of bug fixes  to better handle broken fonts, found
+      by Kostya Serebryany <kcc@google.com>.
+
+
+======================================================================
+
+CHANGES BETWEEN 2.5.5 and 2.6 (2015-Jun-07)
+
+  I. IMPORTANT CHANGES
+
+    - Behdad  Esfahbod contributed  code  for improved  thread-safety,
+      which results in the following model.
+
+      * An `FT_Face' object can only be safely used from one thread at
+        a time.
+
+      * An `FT_Library'  object can  now be used  without modification
+        from multiple threads at the same time.
+
+      * `FT_Face' creation and destruction  with the same `FT_Library'
+        object can only be done from one thread at a time.
+
+      One can use a single  `FT_Library' object across threads as long
+      as a mutex lock is used around `FT_New_Face' and `FT_Done_Face'.
+      Any calls to `FT_Load_Glyph' and similar API are safe and do not
+      need the lock  to be held as  long as the same  `FT_Face' is not
+      used from multiple threads at the same time.
+
+    - Thai script support has been added to the auto-hinter.
+
+    - Arabic script support has been added to the auto-hinter.
+
+    - Following OpenType version 1.7,  advance widths and side bearing
+      values in  CFFs (wrapped  in an SFNT  structure) are  now always
+      taken from the `hmtx' table.
+
+    - Following OpenType  version 1.7, the  PostScript font name  of a
+      CFF font (wrapped in an SFNT structure) is now always taken from
+      the `name'  table.  This is  also true for  OpenType Collections
+      (i.e., TTCs using  CFFs subfonts instead of TTFs),  where it may
+      have a significant difference.
+
+    - Fonts natively hinted for  ClearType are now supported, properly
+      handling selector index 3 of the INSTCTRL bytecode instruction.
+
+    - Major improvements to the GX TrueType variation font handling.
+
+
+  II. MISCELLANEOUS
+
+    - A new auto-hinter  property `warping' can switch on  and off the
+      warping code  if this  experimental feature  is compiled  in (by
+      defining  the AF_CONFIG_OPTION_USE_WARPER  configuration option;
+      by default  this option is  now enabled but warping  is switched
+      off).
+
+      The AF_CONFIG_OPTION_USE_WARPER option itself is an old feature,
+      available   since  2006.    Warping   only   works  in   `light'
+      auto-hinting mode.   The idea of  the code is to  slightly scale
+      and  shift a  glyph  along the  non-hinted  dimension (which  is
+      usually the horizontal axis) so that as much of its segments are
+      aligned  (more or  less) to  the grid.   To find  out a  glyph's
+      optimal   scaling   and   shifting  value,   various   parameter
+      combinations are tried and scored.
+
+      See  file  `ftautoh.h' for  more;  the  demo programs  `ftdiff',
+      `ftview', and `ftgrid' can toggle warping with key `w'.
+
+    - Some  fields  in  the  `FTC_ImageTypeRec'  structure  have  been
+      changed from signed to unsigned  type, which better reflects the
+      actual usage.  It is also an additional means to protect against
+      malformed input.
+
+      This  change doesn't  break  the ABI;  however,  it might  cause
+      compiler warnings.
+
+    - Function `FT_Bitmap_New'  has been renamed  to `FT_Bitmap_Init',
+      since  this name  better reflects  its  function.   For backward
+      compatibility, the old function name is still available.
+
+    - Function   `FT_Get_X11_Font_Format'   has    been   renamed   to
+      `FT_Get_Font_Format',  since  this   name  better  reflects  its
+      function.  For backward compatibility,  the old function name is
+      still available.
+
+      Additionally, the header  file macro for this  function has been
+      renamed to  `FT_FONT_FORMATS_H' (the old name  `FT_XFREE86_H' is
+      retained for backward compatibility).
+
+    - Various improvements to the `ftgrid' demo program.
+
+      . It  can  now  display  GX and  MM  fonts  while  interactively
+        manipulating the axes (with keys F2, F3, and F4).
+
+      . Anti-aliasing rendering  modes can now be  selected (with keys
+        F5 and F6).
+
+      . The display of point numbers can be toggled with key `D'.
+
+    - Various improvements to the `ftdump' demo program.
+
+      . It now displays information on MM and GX variation axes.
+
+      . New  command line option  `-u' makes  it output data  in utf-8
+        encoding.
+
+    - The `ftmulti'  demo program can  now handle up  to six MM  or GX
+      axes.
+
+
+======================================================================
+
+CHANGES BETWEEN 2.5.4 and 2.5.5 (2014-Dec-30)
+
+  I. IMPORTANT BUG FIXES
+
+    - Handling of  uncompressed PCF files works again (bug  introduced
+      in version 2.5.4).
+
+
+======================================================================
+
+CHANGES BETWEEN 2.5.3 and 2.5.4 (2014-Dec-06)
+
+  I. IMPORTANT BUG FIXES
+
+    - A   variant  of   vulnerability  CVE-2014-2240   was  identified
+      (cf.  https://savannah.nongnu.org/bugs/?43661) and  fixed in the
+      new CFF driver.  All users should upgrade.
+
+    - The new auto-hinter code using HarfBuzz crashed for some invalid
+      fonts.
+
+    - Many fixes to better protect against malformed input.
+
+
+  II. IMPORTANT CHANGES
+
+    - Full auto-hinter support of the Devanagari script.
+
+    - Experimental auto-hinter support of the Telugu script.
+
+    - CFF stem darkening behaviour can now be controlled at build time
+      using the eight macros
+
+        CFF_CONFIG_OPTION_DARKENING_PARAMETER_{X,Y}{1,2,3,4}    .
+
+    - Some fields in the `FT_Bitmap'  structure have been changed from
+      signed to unsigned type, which better reflects the actual usage.
+      It  is also  an additional  means to  protect against  malformed
+      input.
+
+      This  change doesn't  break  the ABI;  however,  it might  cause
+      compiler warnings.
+
+
+  III. MISCELLANEOUS
+
+    - Improvements to  the auto-hinter's algorithm to  recognize stems
+      and local extrema.
+
+    - Function `FT_Get_SubGlyph_Info' always returned an error even in
+      case of success.
+
+    - Version  2.5.1 introduced  major bugs  in  the cjk  part of  the
+      auto-hinter, which are now fixed.
+
+    - The  `FT_Sfnt_Tag'  enumeration  values  have  been  changed  to
+      uppercase,  e.g.  `FT_SFNT_HEAD'.   The lowercase  variants  are
+      deprecated.    This  is   for  orthogonality   with  all   other
+      enumeration (and enumeration-like) values in FreeType.
+
+    - `cmake' now supports builds of FreeType as an OS X framework and
+      for iOS.
+
+    - Improved project files for vc2010, introducing a property file.
+
+    - The  documentation generator  for  the API  reference  has  been
+      updated to produce  better HTML code (with proper  CSS).  At the
+      same time, the documentation got a better structure.
+
+    - The FT_LOAD_BITMAP_CROP flag is obsolete;  it is not used by any
+      driver.
+
+    - The  TrueType  DELTAP[123]  bytecode instructions  now  work  in
+      subpixel hinting  mode as described in  the ClearType whitepaper
+      (i.e., for touched points in the non-subpixel direction).
+
+    - Many small improvements to the internal arithmetic routines.
+
+
+======================================================================
+
+CHANGES BETWEEN 2.5.2 and 2.5.3 (2014-Mar-06)
+
+  I. IMPORTANT BUG FIXES
+
+    - A vulnerability (CVE-2014-2240) was  identified and fixed in the
+      new  CFF driver  (cf.  https://savannah.nongnu.org/bugs/?41697).
+      All users should upgrade.
+
+    - More  bug  fixes related  to  correct  positioning of  composite
+      glyphs.
+
+    - Many fixes to better protect against malformed input.
+
+
+  II. IMPORTANT CHANGES
+
+    - FreeType can now use the HarfBuzz library to greatly improve the
+      auto-hinting of  fonts that  use OpenType features:  Many glyphs
+      that are part  of such features but don't have  cmap entries are
+      now handled  properly, for  example small caps  or superscripts.
+      Define the configuration  macro FT_CONFIG_OPTION_USE_HARFBUZZ to
+      activate HarfBuzz support.
+
+      You need HarfBuzz version 0.9.19 or newer.
+
+      Note that HarfBuzz depends on  FreeType; this currently causes a
+      chicken-and-egg problem  that can be  solved as follows  in case
+      HarfBuzz is not yet installed on your system.
+
+        1. Compile  and  install  FreeType without  the  configuration
+           macro FT_CONFIG_OPTION_USE_HARFBUZZ.
+
+        2. Compile and install HarfBuzz.
+
+        3. Define  macro  FT_CONFIG_OPTION_USE_HARFBUZZ, then  compile
+           and install FreeType again.
+
+      With FreeType's  `configure' script the procedure  boils down to
+      configure, build, and install FreeType, then configure, compile,
+      and  install  HarfBuzz,  then configure,  compile,  and  install
+      FreeType again (after executing `make distclean').
+
+    - All  libraries FreeType  depends on  are now  checked using  the
+      `pkg-config' configuration files  first, followed by alternative
+      methods.
+
+    - The  new  value  `auto'  for the  various  `--with-XXX'  library
+      options   (for   example   `--with-harfbuzz=auto')   makes   the
+      `configure' script automatically link to the libraries it finds.
+      This is now the default.
+
+    - In case FreeType's `configure' script  can't find a library, you
+      can  pass environment  variables to  circumvent pkg-config,  and
+      those variables  have been  harmonized as  a consequence  of the
+      changes mentioned above:
+
+        LIBZ           -> removed; use LIBZ_CFLAGS and LIBZ_LIBS
+        LIBBZ2         -> removed; use BZIP2_CFLAGS and BZIP2_LIBS
+        LIBPNG_LDFLAGS -> LIBPNG_LIBS
+
+      `./configure --help' shows all available environment variables.
+
+    - The `freetype-config'  script now understands  option `--static'
+      to emit static linking information.
+
+
+======================================================================
+
+CHANGES BETWEEN 2.5.1 and 2.5.2 (2013-Dec-08)
+
+  I. IMPORTANT BUG FIXES
+
+    - Improving the display of some broken TrueType fonts introduced a
+      bug  that made  FreeType crash  on some  popular (but  not fully
+      conformant) fonts like `ahronbd.ttf'.
+
+    - Another round of improvements to correct positioning and hinting
+      of composite glyphs in TrueType fonts.
+
+
+  II. MISCELLANEOUS
+
+    - Version  2.5.1  introduced a  bug  in  handling embedded  bitmap
+      strikes of  TrueType fonts,  causing garbage display  under some
+      circumstances.
+
+    - The   `ftgrid'   demo   program    couldn't   be   compiled   in
+      non-development builds.
+
+
+======================================================================
+
+CHANGES BETWEEN 2.5 and 2.5.1 (2013-Nov-25)
+
+  I. IMPORTANT BUG FIXES
+
+    - For  some WinFNT  files,  the last  glyph  wasn't displayed  but
+      incorrectly marked as invalid.
+
+    - The vertical size of glyphs was  incorrectly set after a call to
+      `FT_GlyphSlot_Embolden', resulting in clipped glyphs.
+
+    - Many fields of the `PCLT' table in SFNT based fonts (if accessed
+      with `FT_Get_Sfnt_Table') were computed incorrectly.
+
+    - In TrueType fonts,  hinting of composite glyphs  could sometimes
+      deliver  incorrect positions  of  components or  even  distorted
+      shapes.
+
+
+  II. IMPORTANT CHANGES
+
+    - WOFF font format support has been added.
+
+    - The auto-hinter now supports Hebrew.  Greek and Cyrillic support
+      has been improved.
+
+    - Support for the forthcoming `OS/2'  SFNT table version 5, as can
+      be found e.g. in the `Sitka' font family for Windows 8.1.
+
+    - The header  file layout  has been changed.   After installation,
+      all files are now located in `<prefix>/include/freetype2'.
+
+      Applications  that  use   (a)  `freetype-config'  or  FreeType's
+      `pkg-config' file to get the include directory for the compiler,
+      and (b) the documented way for header inclusion like
+
+        #include <ft2build.h>
+        #include FT_FREETYPE_H
+        ...
+
+      don't need any change to the source code.
+
+
+  III. MISCELLANEOUS
+
+    - The stem  darkening feature  of the  new CFF  engine can  now be
+      fine-tuned with the new `darkening-parameters' property.
+
+    - `ftgrid' has been updated to toggle various engines with the `H'
+      key, similar to `ftview' and `ftdiff'.
+
+    - The functionality of `ttdebug' has been greatly enhanced.
+
+      . It now displays twilight, storage, and control value data; key
+        `T' shows the twilight point  table, key `S' the storage data,
+        and key `C' the control value table.
+
+      . Some  keys  have  been  reassigned  from  lowercase  to  their
+        uppercase equivalents; for example `q'  to quit the program is
+        now `Q'.
+
+      . Key `f' finishes the current function.
+
+      . Key `R' restarts the debugger.
+
+      . Keys `b' and `p' set a breakpoint.
+
+      . Key `B' provides a function call backtrace.
+
+    - Better support of ARMv7 and x86_64 processors.
+
+    - Apple's `sbix' color bitmap format is now supported.
+
+    - Improved   auto-hinter  rendering   for  many   TrueType  fonts,
+      especially in the range 20-40ppem.
+
+    - A  new face  flag  `FT_FACE_FLAG_COLOR' has  been  added (to  be
+      accessed with the macro `FT_HAS_COLOR').
+
+    - `FT_Gzip_Uncompress'   (modeled    after   zlib's   `uncompress'
+      function)  has been  added; this  is a  by-product of  the newly
+      added WOFF support.
+
+    - Support for  a build with  `cmake' has been contributed  by John
+      Cary <cary@txcorp.com>.
+
+    - Support for x64  builds with Visual C++ has  been contributed by
+      Kenneth Miller <kennethadammiller@yahoo.com>
+
+    - Manual pages for most demo programs have been added.
+
+    - The GETINFO bytecode instruction for TrueType fonts was buggy if
+      used to retrieve subpixel hinting information.  It was necessary
+      to set  selector bit 6  to get  results for selector  bits 7-10,
+      which is wrong.
+
+    - Improved computation  of emulated vertical metrics  for TrueType
+      fonts.
+
+    - Fixed horizontal start-up position of vertical phantom points in
+      TrueType bytecode.
+
+
+======================================================================
+
+CHANGES BETWEEN 2.4.12 and 2.5 (2013-Jun-19)
+
+  I. IMPORTANT BUG FIXES
+
+    - The cache manager function `FTC_Manager_Reset'  didn't flush the
+      cache.
+
+
+  II. IMPORTANT CHANGES
+
+    - Behdad Esfahbod  (on behalf  of Google) contributed  support for
+      color embedded bitmaps (eg. color emoji).
+
+      A  new  load  flag,  FT_LOAD_COLOR, makes  FreeType  load  color
+      embedded-bitmaps, following this draft specification
+
+        https://color-emoji.googlecode.com/git/specification/v1.html
+
+      which defines two new SFNT  tables, `CBDT' and `CBLC' (named and
+      modeled  after  `EBDT'  and `EBLC',  respectively).   The  color
+      bitmaps  are  stored in  the  new  FT_PIXEL_MODE_BGRA format  to
+      represent BGRA  pre-multiplied sRGB  images.  If PNG  support is
+      available,  PNG color  images as  defined in  the same  proposed
+      specification are supported also.
+
+      Note that  color bitmaps  are converted  to grayscale  if client
+      didn't ask for color.
+
+    - As  announced in  the  previous release,  the  old FreeType  CFF
+      engine  is now  disabled by  default.  It  can be  conditionally
+      compiled     by     defining     the     configuration     macro
+      CFF_CONFIG_OPTION_OLD_ENGINE.
+
+    - As announced in the previous release,  all code related to macro
+      FT_CONFIG_OPTION_OLD_INTERNALS  has been removed,  thus becoming
+      obsolete.
+
+
+  III. MISCELLANEOUS
+
+    - The  property API  (`FT_Property_Get' and  `FT_Property_Set') is
+      now declared as stable.
+
+      The  exception,   however,  are  the   experimental  auto-hinter
+      properties `glyph-to-script-map' and `fallback-script' which are
+      subject to change in a forthcoming release.
+
+    - `ftview' has been updated to  support color embedded bitmaps; it
+      can be toggled on and off  with key `c'.  The small cache toggle
+      is now key `K'.
+
+    - It  is now  possible  to  control the  version  of the  TrueType
+      hinting engine  using the new `interpreter-version'  property of
+      the  `truetype' module:  Versions 35  and 38  (the default)  are
+      supported,  which  roughly  corresponds to  disable  and  enable
+      subpixel hinting support, respectively.
+
+      In  both  `ftview'  and  `ftdiff',  switching  between  the  two
+      versions  can be  done  with  key `H'.   In  the `ftbench'  demo
+      program, command line option `-H'  has been extended to activate
+      the non-default interpreter version.
+
+    - The `ttdebug' program has been further improved.  In particular,
+      it accepts a new command line  option `-H' to select the hinting
+      engine.
+
+    - `ftdump's verbose option has been renamed to `-V'.  For all demo
+      programs, `-v' now shows version information.
+
+    - Another round of TrueType subpixel hinting fixes.
+
+    - The `apinames' tool can now create an import file for NetWare.
+
+    - 64bit compilation of the new CFF engine was buggy.
+
+    - Some fixes to improve robustness in memory-tight situations.
+
+
+======================================================================
+
+CHANGES BETWEEN 2.4.11 and 2.4.12 (2013-May-08)
+
+    - We have another CFF parsing and hinting engine!  Written by Dave
+      Arnold <darnold@adobe.com>,  this work  has been  contributed by
+      Adobe in  collaboration with Google.   It is vastly  superior to
+      the old CFF engine, and it  will replace it in the next release.
+      Right  now,  it  is  still  off by  default,  and  you  have  to
+      explicitly select it using  the new `hinting-engine' property of
+      the cff driver:
+
+        ...
+        #include FT_MODULE_H
+        #include FT_CFF_DRIVER_H
+
+        FT_Library  library;
+        int         engine = FT_CFF_HINTING_ADOBE;
+
+
+        ...
+        FT_Property_Set( library, "cff", "hinting-engine", &engine );
+
+      The code has  a (mature) beta status; we encourage  all users to
+      test it and report any problems.
+
+      In case you want to activate the new CFF engine unconditionally,
+      apply this patch:
+
+--- snip ---
+diff --git a/src/cff/cffobjs.c b/src/cff/cffobjs.c
+index ebcf189..3f2ce6b 100644
+--- a/src/cff/cffobjs.c
++++ b/src/cff/cffobjs.c
+@@ -1056,7 +1056,7 @@
+
+
+     /* set default property values */
+-    driver->hinting_engine    = FT_CFF_HINTING_FREETYPE;
++    driver->hinting_engine    = FT_CFF_HINTING_ADOBE;
+     driver->no_stem_darkening = FALSE;
+
+     return FT_Err_Ok;
+--- snip ---
+
+    - The  macro FT_CONFIG_OPTION_OLD_INTERNALS  is no  longer set  by
+      default.  In  the next  release, we  will completely  remove the
+      associated code.   Please update your  programs in case  you are
+      still using this macro.
+
+
+  II. MISCELLANEOUS
+
+    - The  (top-level)  `configure'  script   now  respects  the  MAKE
+      environment variable  to specify a `make' binary.   For backward
+      compatibility, GNUMAKE still overrides MAKE, though.
+
+    - The `ftview'  and `ftdiff'  demo programs have  been redesigned,
+      showing  more options  permanently  on the  screen, among  other
+      minor improvements.
+
+    - Using the `H'  key, it is now possible to  select the CFF engine
+      in both `ftview' and `ftdiff'.
+
+    - The new command line option `-H' for `ftbench' selects the Adobe
+      CFF engine.
+
+    - It is  now possible  to directly select  the LCD  rendering mode
+      with the keys `A'-`F' in  `ftview'.  The key mapping for cycling
+      through LCD modes  has been changed from `K' and  `L' to `k' and
+      `l', and  toggling custom LCD  filtering is no longer  mapped to
+      key `F' but to key `L'.
+
+    - In `ftdiff',  key `x' toggles  between layout modes:  Either use
+      the  advance width  (this is  new and  now the  default) or  the
+      bounding box information to determine line breaks.
+
+    - For all demo  tools, the new command line option  `-v' shows the
+      version.
+
+    - For the demo tools with a GUI, the new command line options `-w'
+      and `-h' select  the width and the height of  the output window,
+      respectively.
+
+    - The `ttdebug' program was broken and has been reactivated.  Note
+      that this program is not compiled by default.
+
+
+======================================================================
+
+CHANGES BETWEEN 2.4.10 and 2.4.11 (2012-Dec-20)
+
+  I. IMPORTANT BUG FIXES
+
+    - Some vulnerabilities in the  BDF implementation have been fixed.
+      Users of this font format should upgrade.
+
+
+  II. IMPORTANT CHANGES
+
+    - Subpixel  hinting support  has been  contributed by  Infinality,
+      based on Greg Hitchcock's whitepaper at
+
+        https://www.microsoft.com/typography/cleartype/truetypecleartype.aspx
+
+      Originally, it was a separate patch available from
+
+        https://web.archive.org/web/20150710073951/http://www.infinality.net:80/blog/
+
+      and which has been integrated.
+
+      Note that  ClearType support is not  completely implemented!  In
+      particular,  full support  for the  options `compatible_widths',
+      `symmetrical_smoothing,  and  `bgr'  (via the  GETINFO  bytecode
+      instruction) is missing.
+
+      Activation of  subpixel hinting  support can be  controlled with
+      the `TT_CONFIG_OPTION_SUBPIXEL_HINTING' configuration option; it
+      is switched off by default.  This feature is still experimental;
+      we welcome test reports!
+
+    - Support for OpenType collections (OTC) has been added.
+
+    - Pure CFF fonts within an SFNT wrapper are now supported.
+
+
+  III. MISCELLANEOUS
+
+    - Minor rendering improvements to the auto-hinter.
+
+    - `FT_GlyphSlot_Oblique' now uses a shear angle of 12°.
+
+    - Experimental support  to handle `property modules',  for example
+      to control the  behaviour of the auto-hinter.   The API consists
+      of two new functions, `FT_Property_Set' and `FT_Property_Get'.
+
+      The code is  still subject to change and should  not be used for
+      production.
+
+    - The `ftdiff' demo program now supports UTF-8 encoded input files
+      for option `-f'.
+
+    - Using keys `r' and `R', you can now adjust the stroker radius in
+      the `ftview' demo program.
+
+    - Other, minor fixes and improvements.
+
+
+======================================================================
+
+CHANGES BETWEEN 2.4.9 and 2.4.10 (2012-Jun-15)
+
+  I. IMPORTANT BUG FIXES
+
+    - Incremental glyph loading as needed by ghostscript was broken.
+
+
+  II. MISCELLANEOUS
+
+    - A new  function `FT_Outline_EmboldenXY',  contributed by  Alexei
+      Podtelezhnikov.
+
+    - In the `ftview' demo program, key `e' has been replaced with `x'
+      and `y' to  embolden in  the horizontal and  vertical direction,
+      respectively.
+
+    - The glyph  spacing computation  in `FT_GlyphSlot_Embolden'  (and
+      similar code in `ftview') has been improved.
+
+    - Minor  improvements to  the TrueType  bytecode  interpreter  and
+      glyph loader, the auto-hinter, and the B/W rasterizer.
+
+
+======================================================================
+
+CHANGES BETWEEN 2.4.8 and 2.4.9 (2012-Mar-08)
+
+  I. IMPORTANT BUG FIXES
+
+    - Another round of fixes to better handle invalid fonts.   Many of
+      them are vulnerabilities  (see CVE-2012-1126 up to CVE-2012-1144
+      and SA48320) so all users should upgrade.
+
+
+  II. MISCELLANEOUS
+
+    - The `ENCODING -1 <n>' format of BDF fonts is now supported.
+
+    - For BDF fonts,  support for the whole Unicode encoding range has
+      been added.
+
+    - Better TTF support for x_ppem != y_ppem.
+
+    - `FT_Get_Advances' sometimes returned bogus values.
+
+    - The  demo  programs  no  longer  recognize  and  handle  default
+      suffixes; you now have to always specify the complete font name.
+
+    - Better rendering and LCD mode cycling added to `ftview'.
+
+
+======================================================================
+
+CHANGES BETWEEN 2.4.7 and 2.4.8 (2011-Nov-14)
+
+  I. IMPORTANT BUG FIXES
+
+    - Some vulnerabilities in handling CID-keyed PostScript fonts have
+      been fixed; see CVE-2011-3439.
+
+
+  II. MISCELLANEOUS
+
+    - Chris Liddell contributed a new API, `FT_Get_PS_Font_Value',  to
+      retrieve most of the dictionary keys in Type 1 fonts.
+
+
+======================================================================
+
+CHANGES BETWEEN 2.4.6 and 2.4.7 (2011-Oct-18)
+
+  I. IMPORTANT BUG FIXES
+
+    - Some  vulnerabilities in handling Type 1 fonts  have been fixed;
+      see CVE-2011-3256.
+
+
+  II. MISCELLANEOUS
+
+    - FreeType  now properly  handles ZapfDingbats  glyph names  while
+      constructing a Unicode character map (for fonts which don't have
+      one).
+
+
+======================================================================
+
+CHANGES BETWEEN 2.4.5 and 2.4.6 (2011-Jul-29)
+
+  I. IMPORTANT BUG FIXES
+
+    - For TrueType based fonts, the ascender and descender values were
+      incorrect sometimes  (off by a pixel if the ppem value was not a
+      multiple of 5).   Depending on the use you might now  experience
+      a different  layout; the  change should  result in  better, more
+      consistent line spacing.
+
+    - Fix CVE-2011-0226  which causes a  vulnerability while  handling
+      Type 1 fonts.
+
+    - BDF fonts  containing  glyphs with negative values  for ENCODING
+      were  incorrectly  rejected.  This  bug has  been introduced  in
+      FreeType version 2.2.0.
+
+    - David Bevan contributed a major revision of the FreeType stroker
+      code:
+
+      . The behaviour of FT_STROKER_LINEJOIN_BEVEL has been corrected.
+
+      . A new  line join style,  FT_STROKER_LINEJOIN_MITER_FIXED,  has
+        been introduced to support PostScript and PDF miter joins.
+
+      . FT_STROKER_LINEJOIN_MITER_VARIABLE  has been introduced  as an
+        alias for FT_STROKER_LINEJOIN_MITER.
+
+      . Various stroking glitches has been fixed.
+
+
+  II. MISCELLANEOUS
+
+      - SFNT bitmap fonts which contain an outline glyph for `.notdef'
+        only no longer set the FT_FACE_FLAG_SCALABLE flag.
+
+
+======================================================================
+
+CHANGES BETWEEN 2.4.4 and 2.4.5 (2011-Jun-25)
+
+  I. IMPORTANT BUG FIXES
+
+    - A rendering regression  for second-order Bézier curves  has been
+      fixed, introduced in 2.4.3.
+
+
+  II. IMPORTANT CHANGES
+
+    - If autohinting  is not  explicitly disabled,  FreeType now  uses
+      the autohinter if  a TrueType based font doesn't  contain native
+      hints.
+
+    - The load flag FT_LOAD_IGNORE_GLOBAL_ADVANCE_WIDTH  has been made
+      redundant and  is simply ignored;  this means that FreeType  now
+      ignores the global advance width value in TrueType fonts.
+
+
+  III. MISCELLANEOUS
+
+    - `FT_Sfnt_Table_Info' can now return the number of SFNT tables of
+      a font.
+
+    - Support for PCF files compressed with bzip2 has been contributed
+      by Joel  Klinghed.  To  make this  work, the  OS must  provide a
+      bzip2 library.
+
+    - Bradley  Grainger  contributed  project  and  solution  files in
+      Visual Studio 2010 format.
+
+    - Again some fixes to better handle broken fonts.
+
+    - Some improvements to the B/W rasterizer.
+
+    - Fixes to the cache module to improve robustness.
+
+    - Just  Fill Bugs contributed (experimental) code to compute  blue
+      zones for CJK Ideographs, improving the alignment of  horizontal
+      stems at the top or bottom edges.
+
+    - The `ftgrid' demo program  can now display  autohinter segments,
+      to be toggled on and off with key `s'.
+
+
+======================================================================
+
+CHANGES BETWEEN 2.4.3 and 2.4.4 (2010-Nov-28)
+
+  I. IMPORTANT BUG FIXES
+
+    - UVS support (TrueType/OpenType cmap format 14) support is fixed.
+      This regression has been introduced in version 2.4.0.
+
+
+  II. MISCELLANEOUS
+
+    - Detect tricky fonts (e.g. MingLiU)  by the lengths and checksums
+      of Type42-persistent subtables (`cvt ', `fpgm', and `prep') when
+      a TrueType font without family name is given.  The previous fix,
+      introduced in 2.4.3,  was too rigorous,  causing many  subsetted
+      fonts (mainly  from PDF files) displayed badly  because FreeType
+      forced  rendering with  the TrueType bytecode engine  instead of
+      the autohinter.
+
+    - Better support for 64bit platforms.
+
+    - More fixes to improve handling of broken fonts.
+
+
+======================================================================
+
+CHANGES BETWEEN 2.4.2 and 2.4.3 (2010-Oct-03)
+
+  I. IMPORTANT BUG FIXES
+
+    - Fix rendering of certain cubic, S-shaped arcs.   This regression
+      has been introduced in version 2.4.0.
+
+
+  II. MISCELLANEOUS
+
+    - To  fix  the  above  mentioned  rendering  issue,  a  new spline
+      flattening algorithm  has been  introduced which  speeds up both
+      conic and cubic arcs.
+
+    - Handling of broken fonts has been further improved.
+
+
+======================================================================
+
+CHANGES BETWEEN 2.4.1 and 2.4.2 (2010-Aug-06)
+
+  I. IMPORTANT BUG FIXES
+
+    - A stack overflow in CFF Type2 CharStrings interpreter is fixed.
+
+    - Handling Type 42 font deallocation was broken; additionally, the
+      library is now more robust against malformed Type 42 fonts.
+
+
+  II. MISCELLANEOUS
+
+    - Two new functions,  `FT_Reference_Library' (in FT_MODULE_H)  and
+      `FT_Reference_Face'  (in  FT_FREETYPE_H),  have  been  added  to
+      simplify life-cycle management.  A counter gets initialized to 1
+      at the  time an  FT_Library (or  FT_Face) structure  is created.
+      The  two  new   functions  increment  the  respective   counter.
+      `FT_Done_Library' and `FT_Done_Face' then only destroy a library
+      or face if the counter is 1, otherwise they simply decrement the
+      counter.
+
+
+======================================================================
+
+CHANGES BETWEEN 2.4.0 and 2.4.1 (2010-Jul-18)
+
+  I. IMPORTANT CHANGES
+
+    - A serious bug in the  CFF font module prevented  display of many
+      glyphs in CFF fonts like `MinionPro-Regular.otf'.
+
+
+======================================================================
+
+CHANGES BETWEEN 2.3.12 and 2.4.0 (2010-Jul-12)
+
+  I. IMPORTANT CHANGES
+
+    - Since May  2010, all  patents  regarding  the TrueType  bytecode
+      interpreter have expired worldwide.  Consequently, we now define
+      TT_CONFIG_OPTION_BYTECODE_INTERPRETER by  default (and  undefine
+      TT_CONFIG_OPTION_UNPATENTED_HINTING).
+
+    - A new function `FT_Library_SetLcdFilterWeights' is available  to
+      adjust the filter weights set by `FT_Library_SetLcdFilter'.
+
+
+  II. MISCELLANEOUS
+
+    - Thanks to many reports from Robert Święcki, FreeType's stability
+      in handling broken or damaged fonts is much improved.
+
+    - Support  for LCD  filter  control has  been  added to  the  demo
+      programs `ftdiff' and `ftview'.
+
+
+======================================================================
+
+CHANGES BETWEEN 2.3.11 and 2.3.12
+
+  I. IMPORTANT CHANGES
+
+    - For  `FT_Open_Face',  new  parameters  are  available  to ignore
+      preferred family names: FT_PARAM_TAG_IGNORE_PREFERRED_FAMILY and
+      FT_PARAM_TAG_IGNORE_PREFERRED_SUBFAMILY.
+
+
+  II. MISCELLANEOUS
+
+    - Support  for  incremental  font  loading  (controlled  with  the
+      FT_CONFIG_OPTION_INCREMENTAL macro) is now active by default.
+
+    - Better support for vertical metrics.
+
+    - Various minor bug fixes.
+
+
+======================================================================
+
+CHANGES BETWEEN 2.3.10 and 2.3.11
+
+  I. IMPORTANT BUG FIXES
+
+    - Version 2.3.10 broke PCF support.
+
+
+======================================================================
+
+CHANGES BETWEEN 2.3.10 and 2.3.9
+
+  I. IMPORTANT BUG FIXES
+
+    - If all  ASCII digits in a  font have the  same (unscaled) width,
+      the autohinter respects this and won't change it.
+
+    - TrueType fonts  are now  rasterized correctly  if the horizontal
+      and vertical resolution differ.
+
+    - Type 1 fonts are now handled with increased precision internally
+      to avoid serious rounding issues if non-integral coordinates are
+      encountered.
+
+    - Horizontally  condensed CFF  fonts (using the font  matrix) were
+      rendered  incorrectly.   This  bug  has  been  introduced  after
+      release 2.3.5.
+
+
+  II. IMPORTANT CHANGES
+
+    - Support for the SFNT cmap 13 table format (as defined by the new
+      OpenType 1.6 specification) has been added.
+
+    - B/W rasterization  of well-hinted TrueType  fonts at small sizes
+      has been greatly improved.
+
+    - Calculation  of  vertical  metrics in  OpenType  fonts has  been
+      improved.
+
+
+  III. MISCELLANEOUS
+
+    - It  is now  possible to  change  the emboldening  factor in  the
+      `ftview' demo program with keys `e' and `E'.
+
+    - It is  now possible  to change the  slant value in  the `ftview'
+      demo program with keys `s' and `S'.
+
+    - The  5-levels  grayscale  mode of  the `ftraster'  module (which
+      FreeType doesn't use by default) was broken since version 2.3.0.
+
+    - Compilation of the  `ftgrays' and `ftraster' modules  was broken
+      in stand-alone mode.
+
+    - Various fixes for compilation on 64bit and 16bit architectures.
+
+
+======================================================================
+
+CHANGES BETWEEN 2.3.9 and 2.3.8
+
+  I. IMPORTANT BUG FIXES
+
+    - Very unfortunately, FreeType 2.3.8 contained a change that broke
+      its  official ABI.  The  end result  is  that programs  compiled
+      against previous versions of the library, but dynamically linked
+      to  2.3.8 can  experience  memory corruption  if  they call  the
+      `FT_Get_PS_Font_Info' function.
+
+      We recommend all users to  upgrade to 2.3.9 as soon as possible,
+      or to downgrade to a previous  release of the library if this is
+      not an option.
+
+      The  origin of the  bug is  that a  new field  was added  to the
+      publicly  defined  `PS_FontInfoRec'  structure.   Unfortunately,
+      objects of this  type can be stack or  heap allocated by callers
+      of   `FT_Get_PS_Font_Info',  resulting   in   a  memory   buffer
+      overwrite with its implementation in 2.3.8.
+
+      If  you want to  know whether  your code  is vulnerable  to this
+      issue,  simply  search  for  the  substrings  `PS_FontInfo'  and
+      `PS_Font_Info' in your source code.  If none is found, your code
+      is safe and is not affected.
+
+      The FreeType team apologizes for the problem.
+
+    - The POSIX support  of MacOS resource-fork fonts  (Suitcase fonts
+      and LaserWriter Type1 PostScript fonts) was broken in 2.3.8.  If
+      FreeType2 is built without Carbon framework, these fonts are not
+      handled correctly.  Version 2.3.7 didn't have this bug.
+
+    - `FT_Get_Advance' (and `FT_Get_Advances') returned bad values for
+      almost all font formats except TrueType fonts.
+
+    - Fix a bug  in the SFNT  kerning table  loader/parser which could
+      crash the engine if certain malformed tables were encountered.
+
+    - Composite SFNT bitmaps are now handled correctly.
+
+
+  II. IMPORTANT CHANGES
+
+    - The   new  functions   `FT_Get_CID_Is_Internally_CID_keyed'  and
+      `FT_Get_CID_From_Glyph_Index'  can be  used to  access CID-keyed
+      CFF fonts  via CID  values.  This code  has been  contributed by
+      Michael Toftdal.
+
+
+  III. MISCELLANEOUS
+
+    - `FT_Outline_Get_InsideBorder'  returns   FT_STROKER_BORDER_RIGHT
+      for empty outlines.  This was incorrectly documented.
+
+    - The `ftview' demo program now supports UTF-8 encoded strings.
+
+
+======================================================================
+
+CHANGES BETWEEN 2.3.8 and 2.3.7
+
+  I. IMPORTANT BUG FIXES
+
+    - CID-keyed fonts in an SFNT wrapper were not handled correctly.
+
+    - The smooth renderer produced truncated images (on the right) for
+      outline parts with negative horizontal values.  Most fonts don't
+      contain outlines left  to the y coordinate axis, but  the effect
+      was very noticeable for outlines processed with FT_Glyph_Stroke,
+      using thick strokes.
+
+    - `FT_Get_TrueType_Engine_Type'  returned a  wrong  value if  both
+      configuration  macros  TT_CONFIG_OPTION_BYTECODE_INTERPRETER and
+      TT_CONFIG_OPTION_UNPATENTED_HINTING were defined.
+
+    - The  `face_index'  field  in   the  `FT_Face'  structure  wasn't
+      initialized properly after calling FT_Open_Face and friends with
+      a positive face index for CFFs,  WinFNTs, and, most importantly,
+      for TrueType Collections (TTCs).
+
+
+  II. IMPORTANT CHANGES
+
+    - Rudimentary support for Type 1  fonts and CID-keyed Type 1 fonts
+      in an SFNT wrapper has been  added -- such fonts are used on the
+      Mac.  The core  SFNT tables `TYP1' and `CID '  are passed to the
+      PS Type 1  and CID-keyed PS font drivers;  other tables (`ALMX',
+      `BBOX', etc.) are not supported yet.
+
+    - A  new interface  to extract  advance values  of glyphs  without
+      loading their outlines has been added.  The functions are called
+      `FT_Get_Advance' and `FT_Get_Advances'; they are defined in file
+      `ftadvanc.h' (to be accessed as FT_ADVANCES_H).
+
+    - A new function `FT_Get_FSType_Flags' (in FT_FREETYPE_H) has been
+      contributed  by   David  Bevan  to  access   the  embedding  and
+      subsetting restriction information of fonts.
+
+
+  III. MISCELLANEOUS
+
+    - FT_MulFix is now an inlined function; by default, assembler code
+      is provided for x86 and ARM.  See FT_CONFIG_OPTION_INLINE_MULFIX
+      and FT_CONFIG_OPTION_NO_ASSEMBLER (in ftoption.h) for more.
+
+    - The handling of `tricky' fonts  (that is, fonts which don't work
+      with the  autohinter, needing the font  format's hinting engine)
+      has been generalized and changed slightly:
+
+      . A new  face flag  FT_FACE_FLAG_TRICKY indicates that  the font
+        format's  hinting engine is  necessary for  correct rendering.
+        The macro FT_IS_TRICKY can be used to check this flag.
+
+      . FT_LOAD_NO_HINTING is now ignored for tricky fonts.  To really
+        force  raw  loading  of  such fonts  (without  hinting),  both
+        FT_LOAD_NO_HINTING  and FT_LOAD_NO_AUTOHINT  must  be used  --
+        this is something which you probably never want to do.
+
+      . Tricky  TrueType fonts  always use  the  bytecode interpreter,
+        either the patented or unpatented version.
+
+    - The  function  `FT_GlyphSlot_Own_Bitmap'  has  been  moved  from
+      FT_SYNTHESIS_H to FT_BITMAP_H; it  is now part of the `official'
+      API.   (The functions  in  FT_SYNTHESIS_H are  still subject  to
+      change, however.)
+
+    - In the  `ftdiff'  demo  program you  can now  toggle the  use of
+      FT_LOAD_IGNORE_GLOBAL_ADVANCE_WIDTH with key `a'.
+
+
+======================================================================
+
+CHANGES BETWEEN 2.3.7 and 2.3.6
+
+  I. IMPORTANT BUG FIXES
+
+    - If the library  was compiled on an i386  platform using gcc, and
+      compiler  option -O3 was  given, `FT_MulFix'  sometimes returned
+      incorrect  results   which  could  have   caused  problems  with
+      `FT_Request_Metrics'   and  `FT_Select_Metrics',   returning  an
+      incorrect descender size.
+
+    - Pure CFFs without  subfonts were scaled incorrectly  if the font
+      matrix  was  non-standard.  This  bug  has  been  introduced  in
+      version 2.3.6.
+
+    - The  `style_name'  field  in  the  `FT_FaceRec'  structure often
+      contained  a wrong  value for  Type 1  fonts.  This misbehaviour
+      has been  introduced  in  version  2.3.6  while  trying  to  fix
+      another   problem.   [Note,  however,   that   this   value   is
+      informative only  since  the  used  algorithm to  extract  it is
+      very simplistic.]
+
+
+  II. IMPORTANT CHANGES
+
+    - Two      new      macros,      FT_OUTLINE_SMART_DROPOUTS     and
+      FT_OUTLINE_EXCLUDE_STUBS,  have been introduced.   Together with
+      FT_OUTLINE_IGNORE_DROPOUTS (which  was ignored previously) it is
+      now possible to control the dropout mode  of the `raster' module
+      (for B&W rasterization),   using  the   `flags'  field   in  the
+      `FT_Outline' structure.
+
+    - The TrueType bytecode interpreter now passes the dropout mode to
+      the B&W rasterizer.  This greatly increases the output for small
+      ppem values of many fonts like `pala.ttf'.
+
+
+======================================================================
+
+CHANGES BETWEEN 2.3.6 and 2.3.5
+
+  I. IMPORTANT BUG FIXES
+
+    - A  bunch of  potential security  problems have  been found.  All
+      users should update.
+
+    - Microsoft  Unicode  cmaps  in  TrueType  fonts  are  now  always
+      preferred over Apple cmaps.  This is not a bug per se, but there
+      exist some buggy  fonts created for MS which  have broken  Apple
+      cmaps.  This affects  only the automatic  selection of FreeType;
+      it's always possible to manually select an Apple Unicode cmap if
+      desired.
+
+    - Many bug fixes to the TrueType bytecode interpreter.
+
+    - Improved Mac support.
+
+    - Subsetted CID-keyed CFFs are now supported correctly.
+
+    - CID-keyed CFFs with subfonts which are scaled in a  non-standard
+      way are now handled correctly.
+
+    - A call to FT_Open_Face with `face_index' < 0 crashed FreeType if
+      the font was a Windows (bitmap) FNT/FON.
+
+
+  II. IMPORTANT CHANGES
+
+    - The new function `FT_Get_CID_Registry_Ordering_Supplement' gives
+      access to  those fields in a CID-keyed font.  The code  has been
+      contributed by Derek Clegg.
+
+    - George Williams  contributed  code  to validate  the new  `MATH'
+      OpenType  table (within  the `otvalid'  module).  The  `ftvalid'
+      demo program has been extended accordingly.
+
+    - An API for cmap 14 support  (for Unicode Variant Selectors, UVS)
+      has been contributed by George Williams.
+
+    - A new face flag FT_FACE_FLAG_CID_KEYED has been added,  together
+      with a macro FT_IS_CID_KEYED which evaluates to 1 if the font is
+      CID-keyed.
+
+
+  III. MISCELLANEOUS
+
+    - Build support for symbian has been contributed.
+
+    - Better WGL4 glyph name support, contributed by Sergey Tolstov.
+
+    - Debugging output of the  various FT_TRACEX macros is now sent to
+      stderr.
+
+    - The `ftview' demo program now provides artificial slanting too.
+
+    - The `ftvalid' demo  program has a new  option `-f' to select the
+      font index.
+
+
+======================================================================
+
+CHANGES BETWEEN 2.3.5 and 2.3.4
+
+  I. IMPORTANT BUG FIXES
+
+    - Some subglyphs in TrueType fonts were handled incorrectly due to
+      a missing graphics state reinitialization.
+
+    - Large .Z files  (as distributed with some X11  packages) weren't
+      handled correctly, making FreeType increase the heap stack in an
+      endless loop.
+
+    - A large  number of  bugs have  been fixed  to avoid  crashes and
+      endless loops with invalid fonts.
+
+
+  II. IMPORTANT CHANGES
+
+    - The  two new  cache functions  `FTC_ImageCache_LookupScaler' and
+      `FTC_SBit_Cache_LookupScaler' have been added to allow lookup of
+      glyphs using an  `FTC_Scaler' object;  this makes it possible to
+      use fractional pixel sizes in the cache.  The demo programs have
+      been updated accordingly to use this feature.
+
+    - A new API  `FT_Get_CMap_Format' has been added to  get the  cmap
+      format  of a  TrueType font.   This  is useful  in handling  PDF
+      files.  The code has been contributed by Derek Clegg.
+
+    - The  auto-hinter  now  produces  better  output  by  default for
+      non-Latin scripts  like Indic.   This was done by  using the CJK
+      hinting module  as the default instead of the Latin one.  Thanks
+      to Rahul Bhalerao for this suggestion.
+
+    - A new API `FT_Face_CheckTrueTypePatents'  has been added to find
+      out  whether  a  given  TrueType  font  uses  patented  bytecode
+      instructions.   The  `ft2demos' bundle  contains a  new  program
+      called `ftpatchk' which demonstrates its usage.
+
+    - A  new  API  `FT_Face_SetUnpatentedHinting'  has  been  added to
+      enable or disable the unpatented hinter.
+
+    - Support for Windows FON files in PE format  has been contributed
+      by Dmitry Timoshkov.
+
+
+  III. MISCELLANEOUS
+
+    - Vincent Richomme contributed Visual C++ project files for Pocket
+      PCs.
+
+
+======================================================================
+
+CHANGES BETWEEN 2.3.4 and 2.3.3
+
+  I. IMPORTANT BUG FIXES
+
+    - A serious  bug  in  the  handling  of bitmap  fonts (and  bitmap
+      strikes of outline fonts) has been introduced in 2.3.3.
+
+
+======================================================================
+
+CHANGES BETWEEN 2.3.3 and 2.3.2
+
+  I. IMPORTANT BUG FIXES
+
+    - Remove a serious regression in the TrueType bytecode interpreter
+      that was introduced  in version 2.3.2.  Note that  this does not
+      disable  the  improvements  introduced  to  the  interpreter  in
+      version 2.3.2,  only some ill  cases that occurred  with certain
+      fonts (though a few popular ones).
+
+    - The auto-hinter now  ignores single-point contours for computing
+      blue zones.   This bug  created `wavy' baselines  when rendering
+      text  with  various  fonts  that  use these  contours  to  model
+      mark-attach points  (these are points that  are never rasterized
+      and are placed outside of the glyph's real outline).
+
+    - The `rsb_delta' and `lsb_delta' glyph slot fields are now set to
+      zero for mono-spaced fonts.  Otherwise code that uses them would
+      essentially ruin the fixed-advance property.
+
+    - Fix  CVE-2007-1351 which  can  cause an  integer overflow  while
+      parsing  BDF fonts,  leading to  a potentially  exploitable heap
+      overflow condition.
+
+
+  II. MISCELLANEOUS
+
+    - Fixed compilation issues on some 64-bit platforms (see ChangeLog
+      for details).
+
+    - A new demo  program `ftdiff' has been added  to compare TrueType
+      hinting, FreeType's auto  hinting, and rendering without hinting
+      in three columns.
+
+
+======================================================================
+
+CHANGES BETWEEN 2.3.2 and 2.3.1
+
+  I. IMPORTANT BUG FIXES
+
+    - FreeType  returned incorrect  kerning information  from TrueType
+      fonts when the bytecode  interpreter was enabled.  This happened
+      due to a typo introduced in version 2.3.0.
+
+    - Negative  kerning  values  from   PFM  files  are  now  reported
+      correctly  (they were read  as 16-bit  unsigned values  from the
+      file).
+
+    - Fixed  a small  memory leak  when `FT_Init_FreeType'  failed for
+      some reason.
+
+    - The Postscript hinter placed and sized very thin and ghost stems
+      incorrectly.
+
+    - The TrueType bytecode  interpreter has been fixed to  get rid of
+      most of the  rare differences seen in comparison  to the Windows
+      font loader.
+
+
+  II. IMPORTANT CHANGES
+
+    - The auto-hinter  now better deals  with serifs and  corner cases
+      (e.g.,  glyph '9'  in Arial  at 9pt,  96dpi).  It  also improves
+      spacing  adjustments and doesn't  change widths  for non-spacing
+      glyphs.
+
+    - Many   Mac-specific   functions   are  deprecated   (but   still
+      available);  modern replacements  have been  provided  for them.
+      See the documentation in file `ftmac.h'.
+
+
+======================================================================
+
+CHANGES BETWEEN 2.3.1 and 2.3.0
+
+  I. IMPORTANT BUG FIXES
+
+    - The TrueType interpreter sometimes returned incorrect horizontal
+      metrics due to a bug in the handling of the SHZ instruction.
+
+    - A typo  in  a  security  check  introduced  after  version 2.2.1
+      prevented FreeType to render some glyphs in CFF fonts.
+
+
+======================================================================
+
+CHANGES BETWEEN 2.3.0 and 2.2.1
+
+  I. IMPORTANT BUG FIXES
+
+    - The  PCF font  loader  is  now much  more  robust while  loading
+      malformed font files.
+
+    - Various memory leaks have been found and fixed.
+
+    - The TrueType name loader now deals properly with some fonts that
+      encode their  names in UTF-16 (the specification  was vague, and
+      the code incorrectly assumed UCS-4).
+
+    - Fixed the TrueType bytecode  loader to deal properly with subtle
+      monochrome/gray  issues  when   scaling  the  CVT.   Some  fonts
+      exhibited bad rendering artifacts otherwise.
+
+    - `FT_GlyphSlot_Embolden' now  supports vertical layouts correctly
+      (it mangled the vertical advance height).
+
+    - Fixed byte  endian issues  of `ftmac.c' to  support Mac OS  X on
+      i386.
+
+    - The  PFR  font loader  no  longer  erroneously  tags font  files
+      without any outlines as FT_FACE_FLAG_SCALABLE.
+
+
+  II. NEW API FUNCTIONS
+
+    - `FT_Library_SetLcdFilter' allows you  to select a special filter
+      to be  applied to the bitmaps generated  by `FT_Render_Glyph' if
+      one of the FT_RENDER_MODE_LCD and FT_RENDER_MODE_LCD_V modes has
+      been  selected.  This filter  is used  to reduce  color fringes;
+      several  settings are  available  through the  FT_LCD_FILTER_XXX
+      enumeration.
+
+      Its  declaration   and  documentation  can  be   found  in  file
+      `include/freetype/ftlcdfil.h'   (to  be   accessed   with  macro
+      FT_LCD_FILTER_H).
+
+      *IMPORTANT*:     This      function     returns     an     error
+      (FT_Err_Unimplemented_Feature) in default  builds of the library
+      for patent reasons.  See below.
+
+    - `FT_Get_Gasp'  allows you  to query  the flags  of  the TrueType
+      `gasp' table for  a given character pixel size.   This is useful
+      to duplicate  the text rendering  of MS Windows when  the native
+      bytecode  interpreter is  enabled (which  isn't the  default for
+      other patent reasons).
+
+      Its  declaration   and  documentation  can  be   found  in  file
+      `include/freetype/ftgasp.h'   (to   be   accessed   with   macro
+      FT_GASP_H).
+
+
+  III. IMPORTANT CHANGES
+
+    - The auto-hinter has been tuned a lot to improve its results with
+      serif fonts, resulting in much better font rendering of many web
+      pages.
+
+    - The unpatented  hinter is now part  of the default  build of the
+      library; we  have added  code to automatically  support `tricky'
+      fonts that need it.
+
+      This means  that FreeType should `just work'  with certain Asian
+      fonts, like  MingLiU, which cannot properly be  loaded without a
+      bytecode interpreter,  but which fortunately  do not use  any of
+      the patented  bytecode opcodes.  We detect these  fonts by name,
+      so please  report any font file  that doesn't seem  to work with
+      FreeType, and  we shall do what we  can to support it  in a next
+      release.
+
+      Note  that  the API  hasn't  changed,  so  you can  still  force
+      unpatented hinting with a special parameter to `FT_Open_Face' as
+      well.  This  might be useful in  same cases; for  example, a PDF
+      reader might present  a user option to activate  it to deal with
+      certain  `tricky'   embedded  fonts  which   cannot  be  clearly
+      identified.
+
+      If you are  a developer for embedded systems,  you might want to
+      *disable*  the   feature  to  save  code   space  by  undefining
+      TT_CONFIG_OPTION_UNPATENTED_HINTING in file `ftoption.h'.
+
+    - LCD-optimized rendering is now  *disabled* in all default builds
+      of  the  library,  mainly   due  to  patent  issues.   For  more
+      information see:
+
+      https://lists.gnu.org/archive/html/freetype/2006-09/msg00064.html
+
+      A  new  configuration macro  FT_CONFIG_OPTION_SUBPIXEL_RENDERING
+      has been introduced in  `ftoption.h'; manually define it in this
+      file if you want to re-enable the feature.
+
+      The  change only  affects the  implementation, not  the FreeType
+      API.  This means that clients don't need to be modified, because
+      the library still generates  LCD decimated bitmaps, but with the
+      added constraint that R=G=B on each triplet.
+
+      The  displayed result  should  be equal  to normal  anti-aliased
+      rendering.
+
+      Additionally,  if   FT_CONFIG_OPTION_SUBPIXEL_RENDERING  is  not
+      defined, the new  `FT_Library_SetLcdFilter' function returns the
+      FT_Err_Unimplemented_Feature error code.
+
+    - Some computation bugs in  the TrueType bytecode interpreter were
+      found,  which  allow us  to  get rid  of  very  subtle and  rare
+      differences we had experienced with the Windows renderer.
+
+    - It is now possible to cross-compile the library easily.  See the
+      file `docs/INSTALL.CROSS' for details.
+
+    - The file `src/base/ftmac.c' now contains code for Mac OS X only;
+      its  deprecated function  `FT_GetFile_From_Mac_Font_Name' always
+      returns an  error even if the QuickDraw  framework is available.
+      The previous version has been moved to `builds/mac/ftmac.c'.
+
+      Selecting  configure option `--with-quickdraw-carbon'  makes the
+      build process use the original `ftmac.c' file instead of the Mac
+      OS X-only version.
+
+
+  IV. MISCELLANEOUS
+
+    - Various performance and memory footprint optimizations have been
+      performed on  the TrueType and CFF font  loaders, sometimes with
+      very drastic  benefits (e.g., the  TrueType loader is  now about
+      25% faster;  FreeType should use  less heap memory  under nearly
+      all conditions).
+
+    - The anti-aliased rasterizer has been optimized and is now 15% to
+      25%  percent  faster than  in  previous  versions, depending  on
+      content.
+
+    - The Type 1 loader has been improved; as an example, it now skips
+      top-level dictionaries properly.
+
+    - Better support for Mac  fonts on POSIX systems, plus compilation
+      fixes for Mac OS X on ppc64 where `ftmac.c' cannot be built.
+
+    - Configuration  without `--with-old-mac-fonts'  does  not include
+      `ftmac.c' (this was the behaviour in FreeType version 2.1.10).
+
+    - The TrueTypeGX validator (gxvalid) checks the order of glyph IDs
+      in the kern table.
+
+
+======================================================================
+
+CHANGES BETWEEN 2.2.1 and 2.2
+
+  I. IMPORTANT BUG FIXES
+
+    - Various integer overflows have been fixed.
+
+    - PFB fonts with MacOS resource fork weren't  handled correctly on
+      non-MacOS platforms.
+
+
+======================================================================
+
+CHANGES BETWEEN 2.2 and 2.1.10
+
+(not released officially)
+
+  I. IMPORTANT BUG FIXES
+
+    - Vertical metrics for SFNT fonts were incorrect sometimes.
+
+    - The FT_HAS_KERNING macro always returned 0.
+
+    - CFF OpenType  fonts didn't  return correct vertical  metrics for
+      glyphs with outlines.
+
+    - If FreeType was compiled without hinters, all font formats based
+      on PS outlines weren't scaled correctly.
+
+
+  II. IMPORTANT CHANGES
+
+    - Version 2.2 no longer exposes its internals, that is, the header
+      files  located in  the `include/freetype/internal'  directory of
+      the source package are not  copied anymore by the `make install'
+      command.  Consequently, a number of rogue clients which directly
+      access  FreeType's  internal   functions  and  structures  won't
+      compile without modification.
+
+      We provide  patches for  most of those  rogue clients.   See the
+      following page for more information:
+
+        https://www.freetype.org/freetype2/patches/rogue-patches.html
+
+      Note that, as  a convenience to our Unix  desktop users, version
+      2.2 is *binary* compatible with FreeType 2.1.7, which means that
+      installing this  release on  an existing distribution  shall not
+      break any working desktop.
+
+    - FreeType's build  mechanism has been redesigned.   With GNU make
+      it  is  now  sufficient  in   most  cases  to  edit  two  files:
+      `modules.cfg',  to  select   the  library  components,  and  the
+      configuration  file  `include/freetype/config/ftoption.h' (which
+      can be copied to the objects directory).  Removing unused module
+      directories   to    prevent   its   compilation    and   editing
+      `include/freetype/config/ftmodule.h' is no longer necessary.
+
+    - The  LIGHT  hinting algorithm  produces  more pleasant  results.
+      Also, using the  FT_LOAD_TARGET_LIGHT flags within FT_Load_Glyph
+      always forces auto-hinting, as a special exception.  This allows
+      you to experiment with it  even if you have enabled the TrueType
+      bytecode interpreter in your build.
+
+    - The auto hinter now employs a new algorithm for CJK fonts, based
+      on Akito  Hirai's patch.   Note that this  only works  for fonts
+      with a Unicode charmap at the moment.
+
+    - The following callback function  types have changed slightly (by
+      adding the `const' keyword where appropriate):
+
+        FT_Outline_MoveToFunc
+        FT_Outline_LineToFunc
+        FT_Outline_ConicToFunc
+        FT_Outline_CubicToFunc
+        FT_SpanFunc
+        FT_Raster_RenderFunc
+
+        FT_Glyph_TransformFunc
+        FT_Renderer_RenderFunc
+        FT_Renderer_TransformFunc
+
+      Note that this doesn't affect binary backward compatibility.
+
+    - On MacOS,  new APIs have  been added as replacements  for legacy
+      APIs:  `FT_New_Face_From_FSRef'  for  `FT_New_Face_From_FSSpec',
+      and              `FT_GetFile_From_Mac_ATS_Name'              for
+      `FT_GetFile_From_Mac_Name'.  Legacy APIs are still available, if
+      FreeType is built without disabling them.
+
+    - A new  API `FT_Select_Size'  has been added  to select  a bitmap
+      strike  by its  index.   Code using  other  functions to  select
+      bitmap strikes should be updated to use this function.
+
+    - A  new API  `FT_Get_SubGlyph_Info'  has been  added to  retrieve
+      subglyph data.  This can be  used by rogue clients which used to
+      access the internal headers to get the corresponding data.
+
+    - In 2.1.10, the behaviour of `FT_Set_Pixel_Sizes' was changed for
+      BDF/PCF fonts,  and only  for them.  This  causes inconsistency.
+      In this release,  we undo the change.  The  intent of the change
+      in 2.1.10  is to allow  size selection through  real dimensions,
+      which can now be done through `FT_Request_Size'.
+
+    - Some security  issues were discovered  and fixed in the  CFF and
+      Type  1 loader, causing  crashes of  FreeType by  malformed font
+      files.
+
+
+  III. MISCELLANEOUS
+
+    - The documentation  for FT_LOAD_TARGET_XXX and FT_RENDER_MODE_XXX
+      values now better reflects its usage and differences: One set is
+      used to specify the hinting algorithm, the other to specify  the
+      pixel rendering mode.
+
+    - `FT_New_Face' and `FT_New_Face_From_FSSpec' in ftmac.c have been
+      changed to count supported scalable faces (sfnt, LWFN) only, and
+      to  return the  number of  available faces  via face->num_faces.
+      Unsupported bitmap faces (fbit, NFNT) are ignored.
+
+    - builds/unix/configure  has been  improved for  MacOS X.   It now
+      automatically checks available  functions in Carbon library, and
+      prepare to use newest  functions by default.  Options to specify
+      the  dependencies of  each Carbon  APIs (FSSpec,  FSRef, old/new
+      QuickDraw, ATS)  are available too.  By manual  disabling of all
+      QuickDraw   functionality,  FreeType   can   be  built   without
+      `deprecated   function'   warnings    on   MacOS   10.4.x,   but
+      FT_GetFile_Mac_Name  in  ftmac.c  then  is changed  to  a  dummy
+      function, and returns an `unimplemented' error.  For details see
+      builds/mac/README.
+
+    - SFNT cmap handling has been  improved, mainly to run much faster
+      with CJK fonts.
+
+    - A   new  function   `FT_Get_TrueType_Engine_Type   (declared  in
+      `FT_MODULE_H')  is  provided  to  determine the  status  of  the
+      TrueType   bytecode  interpreter   compiled  into   the  library
+      (patented, unpatented, unimplemented).
+
+    - Vertical metrics of glyphs are  synthesized if the font does not
+      provide such information.  You can tell whether  the metrics are
+      synthesized or not by checking the FT_FACE_FLAG_VERTICAL flag of
+      the face.
+
+    - The demo programs  `ftview' and  `ftstring' have been  rewritten
+      for better readability.   `ftview' has a new switch `-p' to test
+      FT_New_Memory_Face (instead of FT_New_Face).
+
+    - FreeType now honours bit 1 in the `head' table of TrueType fonts
+      (meaning `left sidebearing point at x=0').  This helps with some
+      buggy fonts.
+
+    - Rudimentary support for Adobe's new `SING Glyphlet' format.  See
+
+        https://www.adobe.com/content/dam/acom/en/devnet/font/pdfs/5148.SING_Tutorial.pdf
+
+      for more information.
+
+    - The `ftdump'  program from the `ft2demos' bundle  now shows some
+      information about charmaps.  It  also supports a new switch `-v'
+      to increase verbosity.
+
+    - Better AFM support.  This includes track kerning support.
+
+
+======================================================================
+
+CHANGES BETWEEN 2.1.10 and 2.1.9
+
+  I. IMPORTANT BUG FIXES
+
+    - The size comparison for BDF and PCF files could fail sometimes.
+
+    - Some  CFF files  were still not  loaded  correctly.   Patch from
+      Derek Noonburg.
+
+    - The stroker still had some serious bugs.
+
+    - Boris  Letocha  fixed a  bug in  the  TrueType interpreter:  The
+      NPUSHW instruction wasn't skipped correctly in IF clauses.  Some
+      fonts like `Helvetica 75 Bold' failed.
+
+    - Another  serious  bug  in  handling  TrueType hints  caused many
+      distortions.  It has been introduced in version 2.1.8, and it is
+      highly recommended to upgrade.
+
+    - FreeType didn't properly parse empty Type 1 glyphs.
+
+    - An unbound dynamic buffer growth was fixed in the PFR loader.
+
+    - Several bugs have been fixed in the cache sub-system.
+
+    - FreeType behaved incorrectly when resizing two distinct but very
+      close character pixel sizes through `FT_Set_Char_Size' (Savannah
+      bug #12263).
+
+    - The auto-hinter didn't work properly for fonts without a Unicode
+      charmap -- it even refused to load the glyphs.
+
+
+  II. IMPORTANT CHANGES
+
+    - Many fixes have been applied to drastically reduce the amount of
+      heap   memory   used   by   FreeType,   especially   when  using
+      memory-mapped font files  (which is the default on Unix  systems
+      which support them).
+
+    - The auto-hinter  has been replaced with a new module, called the
+      `auto-fitter'.  It consumes  less memory  than its  predecessor,
+      and it is  prepared to support non-latin scripts  better in next
+      releases.
+
+    - George Williams  contributed code to read  kerning data from PFM
+      files.
+
+    - FreeType   now   uses    the   TT_NAME_ID_PREFERRED_FAMILY   and
+      TT_NAME_ID_PREFERRED_SUBFAMILY   strings   (if   available)  for
+      setting  family  and  style in SFNT  fonts  (patch from Kornfeld
+      Eliyahu Peter).
+
+    - A  new  API `FT_Sfnt_Table_Info'  (in FT_TRUETYPE_TABLES_H)  has
+      been added to retrieve name and size information of SFNT tables.
+
+    - A new API `FT_OpenType_Validate' (in FT_OPENTYPE_VALIDATE_H) has
+      been added to validate OpenType tables  (BASE, GDEF, GPOS, GSUB,
+      JSTF).   After validation  it is  no longer  necessary to  check
+      for errors in those tables while accessing them.
+
+      Note that  this module might  be moved to another library in the
+      future  to avoid  a tight  dependency between  FreeType and  the
+      OpenType specification.
+
+    - A new API in FT_BITMAP_H  (`FT_Bitmap_New', `FT_Bitmap_Convert',
+      `FT_Bitmap_Copy',  `FT_Bitmap_Embolden',  `FT_Bitmap_Done')  has
+      been added.   Its  use is  to convert an  FT_Bitmap structure in
+      1bpp, 2bpp,  4bpp, or 8bpp  format into  another 8bpp FT_Bitmap,
+      probably using a different pitch, and to further manipulate it.
+
+    - A new  API `FT_Outline_Embolden'  (in FT_OUTLINE_H) gives  finer
+      control how outlines are emboldened.
+
+    - `FT_GlyphSlot_Embolden' (in FT_SYNTHESIS_H)  now handles bitmaps
+      also (code contributed  by Chia I Wu).  Note that this  function
+      is still experimental and may be replaced with a better API.
+
+    - The method  how BDF and PCF  bitmap fonts  are accessed has been
+      refined.   Formerly,   FT_Set_Pixel_Sizes  and  FT_Set_Char_Size
+      were  synonyms in  FreeType's  BDF and PCF interface.  This  has
+      changed now.  FT_Set_Pixel_Sizes  should be  used to  select the
+      actual  font dimensions  (the `strike',  which is the sum of the
+      `FONT_ASCENT'    and    `FONT_DESCENT'    properties),     while
+      FT_Set_Char_Size  selects  the  `nominal' size  (the `PIXELSIZE'
+      property).  In both functions, the width parameter is ignored.
+
+
+  III. MISCELLANEOUS
+
+    - The BDF driver  no longer converts  all returned bitmaps  with a
+      depth of 2bpp or 4bpp to a depth of 8bpp.  The documentation has
+      not  mentioned  this  explicitly,  but  implementors  might have
+      relied on this after looking into the source files.
+
+    - A new option `--ftversion' has been  added to freetype-config to
+      return the FreeType version.
+
+    - The  memory  debugger  has  been  updated   to  dump  allocation
+      statistics on  all allocation  sources in the library.   This is
+      useful to  spot greedy  allocations when  loading and processing
+      fonts.
+
+    - We removed a huge array of constant pointers to constant strings
+      in the `psnames' module.   The problem was that  compilations in
+      PIC mode (i.e.,  when generating a  Unix shared object/dll)  put
+      the array  into the non-shared  writable section of  the library
+      since absolute pointers are not relocatable by nature.
+
+      This reduces the memory consumption by approximately 16KByte per
+      process linked  to FreeType.   We now also store  the array in a
+      compressed form (as a trie) which saves about 20KByte of code as
+      well.
+
+    - Kirill  Smelkov provided  patches to make  src/raster/ftraster.c
+      compile stand-alone again.
+
+
+======================================================================
+
+CHANGES BETWEEN 2.1.9 and 2.1.8
+
+  I. IMPORTANT BUG FIXES
+
+    - The function  `FT_Get_CharMap_Index' was only declared,  without
+      any  real  code.   For  consistency,  it  has  been  renamed  to
+      `FT_Get_Charmap_Index'.   (This function is needed  to implement
+      cmap caches.)
+
+    - `FT_Outline_Get_BBox'  sometimes returned  incorrect values  for
+      conic outlines (e.g., for TrueType fonts).
+
+    - Handling of `bhed' table has been fixed.
+
+    - The TrueType driver with enabled byte code interpreter sometimes
+      returned artifacts due to incorrect rounding.  This bug has been
+      introduced after version 2.1.4.
+
+    - The BDF driver dropped the last glyph in the font.
+
+    - The BDF driver now uses the DEFAULT_CHAR property (if available)
+      to select a glyph shape for the undefined glyph.
+
+    - The stroker failed for closed outlines and single points.
+
+
+  II. IMPORTANT CHANGES
+
+    - George  Williams   contributed  code  to   handle  Apple's  font
+      distortion technology found in GX fonts (`avar', `cvar', `fvar',
+      and `gvar' tables;  the Multiple Masters  API has been  slightly
+      extended to cope with the new functionality).
+
+    - The `FT_GlyphSlotRec' structure has been extended:  The elements
+      `lsb_delta' and  `rsb_delta' give the difference  between hinted
+      and  unhinted  left and right  side bearings  if autohinting  is
+      active.  Using those values can improve the inter-letter spacing
+      considerably.   See the documentation of  `FT_GlyphSlotRec'  and
+      the `ftstring' demo program how to use it.
+
+    - Loading TrueType and Type 1 fonts has been made much faster.
+
+    - The stroker is  no longer experimental (but the  cache subsystem
+      still is).
+
+
+  III. MISCELLANEOUS
+
+    - A new  documentation file  `formats.txt' describes various  font
+      formats supported (and not supported) by FreeType.
+
+
+======================================================================
+
+CHANGES BETWEEN 2.1.8 and 2.1.7
+
+  I. IMPORTANT BUG FIXES
+
+    - The native  TrueType hinter contained some  bugs which prevented
+      some fonts to be rendered correctly, most notably Legendum.otf.
+
+    - The PostScript hinter now produces improved results.
+
+    - The  linear advance  width  and height  values were  incorrectly
+      rounded,  making  them virtually  unusable  if  not loaded  with
+      FT_LOAD_LINEAR_DESIGN.
+
+    - Indexing CID-keyed CFF fonts is  now working: The glyph index is
+      correctly  treated as a  CID, similar  to FreeType's  CID driver
+      module.  Note that CID CMap support is still missing.
+
+    - The FT_FACE_FLAG_GLYPH_NAMES flag  is now  set correctly for all
+      font formats.
+
+    - Some subsetted Type 1  fonts weren't parsed correctly.  This bug
+      has been introduced in 2.1.7.  In summary, the Type 1 parser has
+      become more robust.
+
+    - Non-decimal numbers weren't parsed correctly in PS fonts.
+
+    - The WinFNT driver now correctly reports FT_ENCODING_NONE for all
+      but one encoding.  Use  the new FT_WinFNT_ID_XXX values together
+      with `FT_Get_WinFNT_Header' to get the WinFNT charset ID.
+
+    - The descender metrics (face->size->metrics.descender) for WinFNT
+      bitmap fonts had the wrong sign.
+
+    - The (emulated) `seac' support for CFF fonts was broken.
+
+    - The `flex' operator didn't work for CFF fonts.
+
+    - PS glyphs  which  use  the   `hintmask'  operator  haven't  been
+      rendered correctly in some cases.
+
+    - Metrics for BDF and PCF bitmap font formats have been fixed.
+
+    - Autohinting  is now  disabled for  glyphs  which  are vertically
+      distorted  or mirrored  (using a  transformation matrix).   This
+      fixes a bug which produced zero-height glyphs.
+
+    - The   `freetype-config'   script   now  handles   --prefix   and
+      --exec-prefix correctly; it also  returns the proper --rpath (or
+      -R) value if FreeType has been built as a shared library.
+
+
+  II. IMPORTANT CHANGES
+
+    - Both  PCF  and BDF  drivers  now  handle  the SETWIDTH_NAME  and
+      ADD_STYLE_NAME    properties.     Values    are   appended    to
+      face->style_name; example: `Bold SemiCondensed'.
+
+    - The PCF driver now handles bitmap  fonts compressed with the LZW
+      algorithm (extension .pcf.Z, compressed with `compress').
+
+    - A  new  API   function  `FT_Get_CMap_Language_ID'  (declared  in
+      `tttables.h')  is  available  to   get  the  language  ID  of  a
+      TrueType/SFNT cmap.
+
+    - The hexadecimal format of  data after the `StartData' command in
+      CID-keyed Type 1 fonts is now supported.  While this can't occur
+      in  file-based   fonts,  it  can   happen  in  document-embedded
+      resources of PostScript documents.
+
+    - Embedded bitmaps in SFNT-based CFF fonts are now supported.
+
+    - A simple  API is  now available  to control  FreeType's  tracing
+      mechanism if compiled  with FT_DEBUG_LEVEL_TRACE.   See the file
+      `ftdebug.h' for more details.
+
+    - YAMATO Masatake contributed improved  handling of MacOS resource
+      forks on non-MacOS platforms (for example, Linux can mount MacOS
+      file systems).
+
+    - Support for MacOS has been improved; there is now a new function
+      `FT_New_Face_From_FSSpec'  similar to `FT_New_Face'  except that
+      it accepts an FSSpec instead of a path.
+
+    - The cache sub-system has been rewritten.
+
+      - There is now support for deinstallation of faces.
+
+      - A new  API function `FTC_Manager_RemoveFaceID'  has been added
+        to  delete  all  `idle'  nodes  that  correspond  to  a  given
+        FTC_FaceID.  All `locked' nodes  (i.e., those with a reference
+        count > 0), will be modified to prevent them from appearing in
+        further  lookups (they  will  be cleaned  normally when  their
+        reference count reaches 0).
+
+      - There  is  now  support  for point  scaling  (i.e.,  providing
+        character sizes in points + dpis, instead of pixels).
+
+      - Three abstract cache classes are now available:
+
+          FTC_GCache:  Used to store  one glyph  item per  cache node,
+                      with the ability to group common attributes into
+                      `families'.      This    replaces     the    old
+                      FTC_GlyphCache class.
+
+          FTC_ICache: Used to store one FT_Glyph per cache node.  This
+                      extends  FTC_GCache.  Family  definition, family
+                      comparison, and  glyph loading are  however left
+                      to sub-classes.
+
+          FTC_SCache: Used to  store up to 16 small  bitmaps per cache
+                      node.    This    extends   FTC_GCache.    Family
+                      definition, family  comparison and glyph loading
+                      are however left to sub-classes.
+
+      - The file `src/cache/ftcbasic.c' implements:
+
+          FTC_ImageCache: Extends    FTC_ICache;   implements   family
+                          definitions and glyph loading similar to the
+                          old API.
+
+          FTC_SBitCache: Extends    FTC_SCache,    implements   family
+                         definitions and glyph  loading similar to the
+                         old API
+
+        Client  applications  should  be  able to  extend  FTC_GCache,
+        FTC_ICache, or FTC_SCache much more easily (i.e., less code to
+        write, and  less callbacks).  For example,  one could envision
+        caches  that are  capable of  storing  transformed (obliqued),
+        stroked,   emboldened,   or   colored   glyph   images.    Use
+        `ftcbasic.c' as an example.
+
+      - All public  APIs are now  in `include/freetype/ftcache.h', (to
+        be    accessed   as    `FT_CACHE_H').     The   contents    of
+        `include/freetype/cache/' is only  needed by applications that
+        wish to implement their own caches.
+
+      - There were some major performance improvements through the use
+        of  various programming  tricks.   Cache hits  are  up to  70%
+        faster than in the old code.
+
+      - The  FTC_CMapCache has  been simplified.  Charmaps can only be
+        accessed by  index right now.  There  is also a  new API named
+        `FT_Charmap_GetIndex' for this purpose.
+
+      - The  demo programs  have been  updated to  the new  code.  The
+        previous versions will not work with the current one.
+
+      - Using  an invalid face  index in FT_Open_Face and friends  now
+        causes an error even if the font contains a single face only.
+
+
+  III. MISCELLANEOUS
+
+    - Wolfgang Domröse contributed support files for building FreeType
+      on the Atari using the PureC compiler.  Note that the Atari is a
+      16bit platform.
+
+    - Vitaliy Pasternak contributed project files for VS.NET 2003.
+
+
+======================================================================
+
+CHANGES BETWEEN 2.1.7 and 2.1.6
+
+  I. IMPORTANT BUG FIXES
+
+    - Updated  to newest  libtool  version, fixing  build problems  on
+      various platforms.
+
+    - On  Unix  platforms,  `make  install' didn't  copy  the  correct
+      `ftconfig.h' file.
+
+  Note that version 2.1.7  contains the same library  C source code as
+  version 2.1.6.
+
+
+======================================================================
+
+CHANGES BETWEEN 2.1.6 and 2.1.5
+
+  I. IMPORTANT BUG FIXES
+
+    - The PFR  font driver didn't  load kerning tables  correctly, and
+      the functions in FT_PFR_H didn't work at all.
+
+    - Type 1 font  files in  binary format  (PFB) with  an end-of-file
+      indicator weren't accepted by the FreeType engine.
+
+    - Fonts which contain /PaintType  and /StrokeWidth no longer cause
+      a segfault.  This bug has been introduced in version 2.1.5.
+
+    - Fonts  loaded  with   FT_LOAD_RENDER  no  longer  cause  strange
+      results.  This bug has been introduced in version 2.1.5.
+
+    - Some  Windows   (bitmap)  FNT/FON  files   couldn't  be  handled
+      correctly.
+
+
+  II. IMPORTANT CHANGES
+
+    - The internal  module API  has been heavily  changed in  favor of
+      massive simplifications within the font engine.  This also means
+      that authors of third-party modules must adapt their code to the
+      new scheme.
+
+      NOTE:  THE NEW SCHEME IS NOT COMPLETED YET.  PLEASE WAIT UNTIL A
+      FINAL ANNOUNCEMENT!
+
+    - The PostScript  parser has been enhanced to  handle comments and
+      strings   correctly.   Additionally,   more  syntax   forms  are
+      recognized.
+
+    - Added the  optional unpatented hinting system  for TrueType.  It
+      allows  typefaces which  need hinting  to produce  correct glyph
+      forms (e.g., Chinese typefaces  from Dynalab) to work acceptably
+      without infringing Apple patents.   This system is compiled only
+      if  TT_CONFIG_OPTION_COMPILE_UNPATENTED_HINTING  is  defined  in
+      ftoption.h (activated by default).
+
+
+  III. MISCELLANEOUS
+
+    - There  is now  a guard  in the  public header  files  to protect
+      against inclusion of freetype.h from FreeType 1.
+
+    - Direct inclusion of freetype.h  and other public header files no
+      longer works.  You have to use the documented scheme
+
+        #include <ft2build.h>
+        #include FT_FREETYPE_H
+
+      to load freetype.h with  a symbolic name.  This protects against
+      renaming  of public  header  files (which  shouldn't happen  but
+      actually  has, avoiding two  public header  files with  the same
+      name).
+
+
+======================================================================
+
+CHANGES BETWEEN 2.1.5 and 2.1.4
+
+  I. IMPORTANT BUG FIXES
+
+    - Parsing the /CIDFontName field  now removes the leading slash to
+      be in sync with other font drivers.
+
+    - gzip support was buggy.  Some fonts could not be read.
+
+    - Fonts which  have nested subglyphs  more than one level  deep no
+      longer cause a segfault.
+
+    - Creation of synthetic  cmaps for fonts in CFF  format was broken
+      partially.
+
+    - Numeric  font  dictionary entries  for  synthetic  fonts are  no
+      longer overwritten.
+
+    - The font matrix  wasn't applied to the advance  width for Type1,
+      CID, and  CFF fonts.  This caused problems  when loading certain
+      synthetic Type 1 fonts like `Helvetica Narrow'.
+
+    - The test  for the charset registry  in BDF and PCF  fonts is now
+      case-insensitive.
+
+    - FT_Vector_Rotate  sometimes  returned   strange  values  due  to
+      rounding errors.
+
+    - The  PCF  driver  now  returns  the  correct  number  of  glyphs
+      (including an artificial `notdef' glyph at index 0).
+
+    - FreeType now  supports buggy CMaps  which are contained  in many
+      CJK fonts from Dynalab.
+
+    - Opening  an invalid  font  on a  Mac  caused a  segfault due  to
+      double-freeing memory.
+
+    - BDF  fonts  with  more   than  32768  glyphs  weren't  supported
+      properly.
+
+
+  II. IMPORTANT CHANGES
+
+    - Accessing bitmap font formats has been synchronized.  To do that
+      the FT_Bitmap_Size  structure has  been extended to  contain new
+      fields `size', `x_ppem', and `y_ppem'.
+
+    - The FNT driver now returns multiple faces, not multiple strikes.
+
+    - The `psnames'  module has been  updated to the Adobe  Glyph List
+      version 2.0.
+
+    - The `psnames' module now understands `uXXXX[X[X]]' glyph names.
+
+    - The algorithm for guessing the font style has been improved.
+
+    - For fonts in SFNT format, root->height is no longer increased if
+      the line gap  is zero.  There exist fonts  (containing e.g. form
+      drawing  characters) which  intentionally have  a zero  line gap
+      value.
+
+    - ft_glyph_bbox_xxx  flags   are  now  deprecated   in  favour  of
+      FT_GLYPH_BBOX_XXX.
+
+    - ft_module_xxx   flags   are   now   deprecated  in   favour   of
+      FT_MODULE_XXX.
+
+    - FT_ENCODING_MS_{SJIS,GB2312,BIG5,WANSUNG,JOHAB}      are     now
+      deprecated               in               favour              of
+      FT_ENCODING_{SJIS,GB2312,BIG5,WANSUNG,JOHAB}  -- those encodings
+      are not specific to Microsoft.
+
+
+  III. MISCELLANEOUS
+
+    - The  autohinter  has been  further  improved;  for example,  `m'
+      glyphs now retain its vertical symmetry.
+
+    - Partial support of Mac fonts on non-Mac platforms.
+
+    - `make   refdoc'   (after   first   `make')   builds   the   HTML
+      documentation.  You need Python for this.
+
+    - The make build system should  now work more reliably on DOS-like
+      platforms.
+
+    - Support for  EMX gcc  and Watson C/C++  compilers on  MS-DOS has
+      been added.
+
+    - Better VMS build support.
+
+    - Support for the pkg-config  package by providing a `freetype.pc'
+      file.
+
+    - New configure option --with-old-mac-fonts for Darwin.
+
+    - Some source files have been  renamed (mainly to fit into the 8.3
+      naming scheme).
+
+
+======================================================================
+
+CHANGES BETWEEN 2.1.4 and 2.1.3
+
+  I. IMPORTANT BUG FIXES
+
+    - Updated  to newest  libtool  version, fixing  build problems  on
+      various platforms.
+
+    - A fix  in the Gzip stream  reader: It couldn't  read certain .gz
+      files properly due to a  small typo.  In certain cases, FreeType
+      could  also loop  endlessly  when trying  to  load tiny  gzipped
+      files.
+
+    - The configure script now tries  to use the system-wide zlib when
+      it  finds one  (instead of  the  copy found  in src/gzip).   And
+      `freetype-config' has  been updated to return  relevant flags in
+      this case when invoked with `--libs' (e.g. `-lzlib').
+
+    - Certain fonts couldn't be loaded  by 2.1.3 because they lacked a
+      Unicode   charmap  (e.g.   SYMBOL.TTF).    FreeType  erroneously
+      rejected them.
+
+    - The CFF loader was modified to accept fonts which only contain a
+      subset of  their reference charset.  This  prevented the correct
+      use of PDF-embedded fonts.
+
+    - The logic to detect Unicode charmaps has been modified.  This is
+      required to  support fonts which include both  16-bit and 32-bit
+      charmaps (like very  recent asian ones) using the  new 10 and 12
+      SFNT formats.
+
+    - The TrueType  loader now limits  the depth of  composite glyphs.
+      This is necessary to prevent broken fonts to break the engine by
+      blowing the stack with recursive glyph definitions.
+
+    - The CMap cache is now  capable of managing UCS-4 character codes
+      that   are   mapped   through   extended  charmaps   in   recent
+      TrueType/OpenType fonts.
+
+    - The   cache  sub-system   now  properly   manages  out-of-memory
+      conditions  instead of  blindly  reporting them  to the  caller.
+      This means that it will try to empty the cache before restarting
+      its allocations to see if that can help.
+
+    - The  PFR driver  didn't return  the list  of  available embedded
+      bitmaps properly.
+
+    - There was  a nasty  memory leak when  using embedded  bitmaps in
+      certain font formats.
+
+
+  II. IMPORTANT CHANGES
+
+    - David Chester  contributed some enhancements  to the auto-hinter
+      that  significantly increase  the  quality of  its output.   The
+      Postscript hinter was also improved in several ways.
+
+    - The FT_RENDER_MODE_LIGHT render mode was implemented.
+
+    - A new  API function called `FT_Get_BDF_Property'  has been added
+      to FT_BDF_H to  retrieve BDF properties from BDF  _and_ PCF font
+      files.   THIS  IS  STILL  EXPERIMENTAL,  since  it  hasn't  been
+      properly tested yet.
+
+    - A Windows FNT specific API has been added, mostly to access font
+      headers.  This is used by Wine.
+
+    - TrueType tables  without an `hmtx' table are  now tolerated when
+      an  incremental interface  is  used.  This  happens for  certain
+      Type42 fonts passed from Ghostscript to FreeType.
+
+    - The PFR font driver is  now capable of returning the font family
+      and style  names when  they are available  (instead of  the sole
+      `FontID').   This  is  performed  by parsing  an  *undocumented*
+      portion of the font file!
+
+
+  III. MISCELLANEOUS
+
+    - The path stroker in FT_STROKER_H has entered beta stage.  It now
+      works very  well, but  its interface might  change a bit  in the
+      future.  More on this in later releases.
+
+    - The documentation for  FT_Size_Metrics didn't appear properly in
+      the API reference.
+
+    - The file docs/VERSION.DLL has been updated to explain versioning
+      with FreeType  (i.e., comparing release/libtool/so  numbers, and
+      how to use them in autoconf scripts).
+
+    - The  installation  documentation  has been  seriously  revamped.
+      Everything is now in the `docs' directory.
+
+
+======================================================================
+
+CHANGES BETWEEN 2.1.3 and 2.1.2
+
+  I. IMPORTANT BUG FIXES
+
+    - FT_Vector_Transform  had  been  incorrectly modified  in  2.1.2,
+      resulting  in  incorrect   transformations  being  applied  (for
+      example, rotations were processed in opposite angles).
+
+    - The format  8 and 12 TrueType charmap  enumeration routines have
+      been fixed (FT_Get_Next_Char returned invalid values).
+
+    - The  PFR font driver  returned incorrect  advance widths  if the
+      outline  and metrics resolution  defined in  the font  file were
+      different.
+
+    - FT_Glyph_To_Bitmap now returns  successfully when called with an
+      FT_BitmapGlyph argument (it previously returned an error).
+
+    - A bug  in the Type 1  loader that prevented  valid font bounding
+      boxes to be loaded from multiple master fonts.
+
+    - The SFNT  validation code has been rewritten.   FreeType can now
+      load `broken'  fonts that were  usable on Windows, but  not with
+      previous versions of the library.
+
+    - The computation of bearings in the BDF driver has been fixed.
+
+    - The Postscript hinter crashed when trying to hint certain glyphs
+      (more precisely,  when trying to  apply hints to an  empty glyph
+      outline).
+
+    - The  TrueType glyph  loader  now supports  composites in  `Apple
+      format'  (they differ slightly  from Microsoft/OpenType  ones in
+      the way transformation offsets are computed).
+
+    - FreeType was  very slow at opening certain  asian CID/CFF fonts,
+      due to  fixed increment  in dynamic array  re-allocations.  This
+      has  been changed  to  exponential behaviour  to get  acceptable
+      performance.
+
+
+
+  II. IMPORTANT CHANGES
+
+    - The PCF driver now supports gzip-compressed font files natively.
+      This means that  you will be able to use  all these bitmap fonts
+      that  come with  XFree86 with  FreeType (and  libXft/libXft2, by
+      extension).
+
+    - The  automatic and  postscript hinters  have both  been updated.
+      This  results in  a relatively  important increase  of rendering
+      quality since  many nasty defaults have been suppressed.  Please
+      visit the web page:
+
+        https://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 subpixel displays (like LCD
+                                 screens).  THIS IS STILL
+                                 EXPERIMENTAL!
+
+        FT_LOAD_TARGET_LCD_V  :: Same as FT_LOAD_TARGET_LCD, for
+                                 vertical subpixel displays (like
+                                 rotated LCD screens).  THIS IS STILL
+                                 EXPERIMENTAL!
+
+      FT_LOAD_MONOCHROME   is  still   supported,  but   only  affects
+      rendering, not the hinting.
+
+      Note that the `ftview'  demo program available in the `ft2demos'
+      package  has been  updated to  support LCD-optimized  display on
+      non-paletted displays (under Win32 and X11).
+
+    - The  PFR  driver  now  supports embedded  bitmaps  (all  formats
+      supported), and returns correct kerning metrics for all glyphs.
+
+    - The TrueType charmap loader  now supports certain `broken' fonts
+      that load under Windows without problems.
+
+    - The cache API has been slightly modified (it's still a beta!):
+
+       - The type  FTC_ImageDesc has been removed; it  is now replaced
+         by  FTC_ImageTypeRec.   Note that  one  of  its  fields is  a
+         `load_flag' parameter for FT_Load_Glyph.
+
+       - The  field  `num_grays' of  FT_SBitRec  has  been changed  to
+         `max_grays'  in  order to  fit  within  a  single byte.   Its
+         maximum value is thus 255 (instead of 256 as previously).
+
+
+  III. MISCELLANEOUS
+
+    - Added support  for the  DESTDIR variable during  `make install'.
+      This simplifies packaging of FreeType.
+
+    - Included modified  copies of the  ZLib sources in  `src/gzip' in
+      order to support  gzip-compressed PCF fonts.  We do  not use the
+      system-provided  zlib  for  now,   though  this  is  a  probable
+      enhancement for future releases.
+
+    - The DocMaker tool used to generate the on-line API reference has
+      been   completely    rewritten.    It   is    now   located   in
+      `src/tools/docmaker/docmaker.py'.  Features:
+
+        - better cross-referenced output
+        - more polished output
+        - uses Python regular expressions  (though it didn't speed the
+          program)
+        - much  more  modular structure,  which  allows for  different
+          `backends'  in  order to  generate  HTML,  XML, or  whatever
+          format.
+
+      One can regenerate the API reference by calling:
+
+         python src/tools/docmaker/docmaker.py \
+                --prefix=ft2 \
+                --title=FreeType-2.1.3 \
+                --output=<outputdirectory>
+                include/freetype/*.h \
+                include/freetype/config/*.h \
+                include/freetype/cache/*.h
+
+    - A new, experimental, support for incremental font loading (i.e.,
+      loading  of fonts  where the  glyphs are  not in  the  font file
+      itself, but provided by an external component, like a Postscript
+      interpreter) has been added by Graham Asher.  This is still work
+      in progress, however.
+
+    - A new,  EXPERIMENTAL, path stroker  has been added.   It doesn't
+      suffer  from  severe  rounding  errors  and  treat  bezier  arcs
+      directly.  Still work in progress (i.e. not part of the official
+      API).   See  the file  <freetype/ftstroker.h>  for  some of  the
+      details.
+
+    - The massive  re-formatting of sources and  internal re-design is
+      still under-way.  Many  internal functions, constants, and types
+      have been renamed.
+
+
+======================================================================
+
+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.
+
+
+======================================================================
+
+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  the results 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.
+
+
+======================================================================
+
+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:
+
+        https://www.freetype.org/freetype2/redesign.html
+
+      The following  internal changes  have been performed  within the
+      sources of this release:
+
+        - Many   internal  types   have  been   renamed   to  increase
+          consistency.   The  following  should  be true,  except  for
+          public types:
+
+            * All structure  types have a name ending  in `Rec' (short
+              for `record').
+
+            * A  pointer-to-structure type  has the  same name  as the
+              structure, _without_ the `Rec' suffix.
+
+              Example:
+
+                typedef struct FooRec_
+                {
+                  ...
+
+                } FooRec, *Foo;
+
+        - Many   internal  macros  have   been  renamed   to  increase
+          consistency.  The following should be true:
+
+            * All  macros  have a  name  beginning  with `FT_'.   This
+              required a few changes like
+
+                ALLOC   => FT_ALLOC
+                FREE    => FT_FREE
+                REALLOC => FT_REALLOC
+
+            * All  macros are completely  UPPERCASE.  This  required a
+              few changes like:
+
+                READ_Short  => FT_READ_SHORT
+                NEXT_Short  => FT_NEXT_SHORT
+                GET_ULongLE => FT_GET_ULONG_LE
+                MEM_Set     => FT_MEM_SET
+                MEM_Copy    => FT_MEM_COPY
+                etc.
+
+            * Whenever   possible,   all   macro  names   follow   the
+              FT_<OBJECT>_<METHOD> pattern.  For example
+
+                ACCESS_Frame   => FT_FRAME_ENTER
+                FORGET_Frame   => FT_FRAME_EXIT
+                EXTRACT_Frame  => FT_FRAME_EXTRACT
+                RELEASE_Frame  => FT_FRAME_RELEASE
+
+                FILE_Pos       => FT_STREAM_POS
+                FILE_Seek      => FT_STREAM_SEEK
+                FILE_Read      => FT_STREAM_READ
+                FILE_ReadAt    => FT_STREAM_READ_AT
+                READ_Fields    => FT_STREAM_READ_FIELDS
+
+        - Many  internal functions  have  been renamed  to follow  the
+          FT_<Object>_<Method> pattern.  For example:
+
+            FT_Seek_Stream       => FT_Stream_Seek
+            FT_Read_Stream_At    => FT_Stream_ReadAt
+            FT_Done_Stream       => FT_Stream_Close
+            FT_New_Stream        => FT_Stream_Open
+            FT_New_Memory_Stream => FT_Stream_OpenMemory
+            FT_Extract_Frame     => FT_Stream_ExtractFrame
+
+          Note that method names do not contain `_'.
+
+        - The FT_ALLOC_ARRAY  and FT_REALLOC_ARRAY have  been replaced
+          with  FT_NEW_ARRAY and  FT_RENEW_ARRAY which  do not  take a
+          type  as the  fourth argument.   Instead, the  array element
+          type  size is computed  automatically from  the type  of the
+          target pointer used.
+
+        - A  new object  class, FT_CMap,  has been  introduced.  These
+          internal  objects are  used to  model character  maps.  This
+          eases  the support  of additional  charmap types  within the
+          engine.
+
+        - A new  configuration file named `ftstdlib.h'  has been added
+          to `include/freetype/config'.  It  is used to define aliases
+          for  _every_ routine  of the  ISO  C library  that the  font
+          engine   uses.    Each    aliases   has   a   `ft_'   prefix
+          (e.g. `ft_strlen' is an alias for `strlen').
+
+          This is  used to  ease the porting  of FreeType 2  to exotic
+          runtime environments where the ISO C Library isn't available
+          (e.g.  XFree86 extension modules).
+
+      More details are available in the `ChangeLog' file.
+
+
+======================================================================
+
+CHANGES BETWEEN 2.0.9 and 2.0.8
+
+  I. IMPORTANT BUG FIXES
+
+    - Certain fonts like `foxjump.ttf' contain broken name tables with
+      invalid entries and wild offsets.  This caused FreeType to crash
+      when trying to load them.
+
+      The  SFNT `name'  table  loader has  been  fixed to  be able  to
+      support these strange fonts.
+
+      Moreover, the code  in charge of processing this  table has been
+      changed  to always favour  Windows-formatted entries  over other
+      ones.  Hence,  a font that works  on Windows but not  on the Mac
+      will  load cleanly in  FreeType and  report accurate  values for
+      Family & PostScript names.
+
+    - The CID font driver has been fixed.  It unfortunately returned a
+      Postscript   Font   name   with   a   leading   slash,   as   in
+      `/MunhwaGothic-Regular'.
+
+    - FreeType  2 should now  compile fine  on AIX  4.3.3 as  a shared
+      library.
+
+    - A  bug  in the  Postscript  hinter  has  been found  and  fixed,
+      removing un-even stem widths at small pixel sizes (like 14-17).
+
+      This  improves the  quality of  a certain  number  of Postscript
+      fonts.
+
+
+  II. NEW FEATURES
+
+    - A  new function  named  `FT_Library_Version' has  been added  to
+      return  the current  library's major,  minor, and  patch version
+      numbers.   This is  important since  the  macros FREETYPE_MAJOR,
+      FREETYPE_MINOR,  and  FREETYPE_PATCH  cannot  be used  when  the
+      library is dynamically linked by a program.
+
+    - Two   new  APIs   have  been   added:   `FT_Get_First_Char'  and
+      `FT_Get_Next_Char'.
+
+      Together,  these can  be used  to iterate  efficiently  over the
+      currently  selected  charmap of  a  given  face.   Read the  API
+      reference for more details.
+
+
+  III. MISCELLANEOUS
+
+    - The FreeType sources are  under heavy internal re-factoring.  As
+      a consequence,  we have created  a branch named `STABLE'  on the
+      CVS to hold all future releases/fixes in the 2.0.x family.
+
+      The  HEAD  branch  now  contains  the  re-factored  sources  and
+      shouldn't  be used for  testing or  packaging new  releases.  In
+      case you  would like  to access the  2.0.9 sources from  our CVS
+      repository, use the tag `VER-2-0-9'.
+
+
+======================================================================
+
+CHANGES BETWEEN 2.0.8 and 2.0.7
+
+  I. IMPORTANT BUG FIXES
+
+    - There was  a small but  nasty bug in  `freetype-config.in' which
+      caused the `freetype-config' script to fail on Unix.
+
+      This didn't prevent the installation  of the library or even its
+      execution, but caused problems  when trying to compile many Unix
+      packages that depend on it.
+
+    - Some TrueType or OpenType fonts embedded in PDF documents do not
+      have  a  'cmap',  'post'  and  'name'  as  is  required  by  the
+      specification.  FreeType no longer refuses to load such fonts.
+
+    - Various fixes to the PCF font driver.
+
+
+======================================================================
+
+CHANGES BETWEEN 2.0.7 and 2.0.6
+
+  I. IMPORTANT BUG FIXES
+
+    - Fixed  two  bugs in  the  Type 1  font  driver.   The first  one
+      resulted in a memory leak in subtle cases.  The other one caused
+      FreeType to crash when  trying to load `.gsf' files (Ghostscript
+      so-called Postscript fonts).
+
+      (This  made _many_  KDE applications  crash on  certain systems.
+       FreeType _is_ becoming a critical system component on Linux :-)
+
+    - Fixed a memory leak in the CFF font driver.
+
+    - Fixed a memory leak in the PCF font driver.
+
+    - Fixed       the        Visual       C++       project       file
+      `builds/win32/visualc/freetype.dsp' since  it didn't include the
+      Postscript hinter component, causing errors at build time.
+
+    - Fixed a  small rendering bug  in the anti-aliased  renderer that
+      only  occurred when  trying to  draw  thin (less  than 1  pixel)
+      strokes.
+
+    - Fixed  `builds/unix/freetype2.a4' which  is used  to  generate a
+      valid `freetype2.m4' for use with autoconf.
+
+    - Fixed the OpenVMS Makefiles.
+
+
+  II. MISCELLANEOUS
+
+    - Added  `configure'  and   `install'  scripts  to  the  top-level
+      directory.  A GNU-style installation is thus now easily possible
+      with
+
+        ./configure  <options>
+        make
+        make install
+
+
+======================================================================
+
+CHANGES BETWEEN 2.0.6 and 2.0.5
+
+  I. IMPORTANT BUG FIXES
+
+    - It wasn't possible to load embedded bitmaps when the auto-hinter
+      was used.  This is now fixed.
+
+    - The TrueType  font driver  didn't load some  composites properly
+      (the  sub-glyphs  were  slightly  shifted,  and  this  was  only
+      noticeable when using monochrome rendering).
+
+    - Various  fixes  to the  auto-hinter.   They  merely improve  the
+      output of sans-serif fonts.   Note that there are still problems
+      with serifed fonts and composites (accented characters).
+
+    - All scalable  font drivers erroneously  returned un-fitted glyph
+      advances when hinting was  requested.  This created problems for
+      a number  of layout applications.  This  is a very  old bug that
+      got  undetected mainly  because most  test/demo  program perform
+      rounding explicitly or implicitly (through the cache).
+
+    - `FT_Glyph_To_Bitmap' did erroneously  modify the source glyph in
+      certain cases.
+
+    - `glnames.py'  still contained  a bug  that made  FreeType return
+      invalid names for certain glyphs.
+
+    - The  library crashed  when  loading certain  Type  1 fonts  like
+      `sadn.pfb'  (`Stalingrad  Normal'),   which  appear  to  contain
+      pathetic font info dictionaries.
+
+    - The TrueType glyph  loader is now much more  paranoid and checks
+      everything when loading a given glyph image.  This was necessary
+      to avoid problems (crashes and/or memory overwrites) with broken
+      fonts that came from a really buggy automatic font converter.
+
+
+  II. IMPORTANT UPDATES AND NEW FEATURES
+
+    - Important updates to the Mac-specific parts of the library.
+
+    - The caching sub-system has  been completely re-designed, and its
+      API has  evolved (the  old one is  still supported  for backward
+      compatibility).
+
+      The documentation for it is  not yet completed, sorry.  For now,
+      you are encouraged to continue  using the old API.  However, the
+      ftview  demo program in  the ft2demos  package has  already been
+      updated to use the new caching functions.
+
+    - A new charmap cache is provided too.  See `FTC_CMapCache'.  This
+      is useful to perform  character code -> glyph index translations
+      quickly, without the need for an opened FT_Face.
+
+    - A NEW POSTSCRIPT HINTER module  has been added to support native
+      hints in  the following  formats: PostScript Type  1, PostScript
+      CID, and CFF/CEF.
+
+      Please test!  Note that  the auto-hinter produces better results
+      for a number of  badly-hinted fonts (mostly auto-generated ones)
+      though.
+
+    - A memory debugger is now  part of the standard FreeType sources.
+      To      enable      it,      define      FT_DEBUG_MEMORY      in
+      <freetype/config/ftoption.h>, and recompile the library.
+
+      Additionally, define  the _environment_ variable FT_DEBUG_MEMORY
+      and run any program using FreeType.  When the library is exited,
+      a  summary  of memory  footprints  and  possible  leaks will  be
+      displayed.
+
+      This works transparently with  _any_ program that uses FreeType.
+      However, you  will need a lot  of memory to  use this (allocated
+      blocks are never  released to the heap to  detect double deletes
+      easily).
+
+
+  III. MISCELLANEOUS
+
+    - We  are  aware  of  subtle  differences between  the  output  of
+      FreeType  versions   1  and  2  when  it   comes  to  monochrome
+      TrueType-hinted glyphs.   These are  most probably due  to small
+      differences in the monochrome rasterizers and will be worked out
+      in an upcoming release.
+
+    - We have decided to fork the sources in a `stable' branch, and an
+      `unstable' one, since FreeType  is becoming a critical component
+      of many Unix systems.
+
+      The next  bug-fix releases of  the library will be  named 2.0.7,
+      2.0.8, etc.,  while the `2.1'  branch will contain a  version of
+      the sources where we will start major reworking of the library's
+      internals, in order to produce FreeType 2.2.0 (or even 3.0) in a
+      more distant future.
+
+      We  also hope  that this  scheme will  allow much  more frequent
+      releases than in the past.
+
+
+======================================================================
+
+CHANGES BETWEEN 2.0.5 and 2.0.4
+
+  NOTE THAT 2.0.5 DOES NOT CONTAIN THE POSTSCRIPT HINTER.  THIS MODULE
+  WILL BE PART OF THE NEXT RELEASE (EITHER 2.0.6 or 2.1)
+
+  - Fixed a bug that made  certain glyphs, like `Cacute', `cacute' and
+    `lslash'  unavailable from Unicode  charmaps of  Postscript fonts.
+    This prevented the correct display of Polish text, for example.
+
+  - The kerning table of Type 1 fonts was loaded by FreeType, when its
+    AFM    file    was    attached    to    its    face,    but    the
+    FT_FACE_FLAG_HAS_KERNING   bit  flags   was  not   set  correctly,
+    preventing FT_Get_Kerning to return meaningful values.
+
+  - Improved  SFNT (TrueType  & OpenType)  charmap  support.  Slightly
+    better performance, as well as support for the new formats defined
+    by the OpenType 1.3 specification (8, 10, and 12)
+
+  - Fixed a  serious typo in `src/base/ftcalc.c'  which caused invalid
+    computations in certain rare cases, producing ugly artefacts.
+
+  - The  size  of the  EM  square is  computed  with  a more  accurate
+    algorithm for Postscript fonts.   The old one caused slight errors
+    with embedded fonts found in PDF documents.
+
+  - Fixed  a  bug in  the  cache  manager  that prevented  normal  LRU
+    behaviour  within the cache  manager, causing  unnecessary reloads
+    (for FT_Face and FT_Size objects only).
+
+  - Added  a new  function named  `FT_Get_Name_Index' to  retrieve the
+    glyph index of a given glyph name, when found in a face.
+
+  - Added  a new function  named `FT_Get_Postscript_Name'  to retrieve
+    the `unique' Postscript font name of a given face.
+
+  - Added   a   new   public   header  size   named   FT_SIZES_H   (or
+    <freetype/ftsizes.h>) providing  new FT_Size-management functions:
+    FT_New_Size, FT_Activate_Size, FT_Done_Size.
+
+  - Fixed a  reallocation bug that  generated a dangling  pointer (and
+    possibly    memory    leaks)    with    Postscript    fonts    (in
+    src/psaux/psobjs.c).
+
+  - Many fixes for 16-bit correctness.
+
+  - Removed many pedantic compiler warnings from the sources.
+
+  - Added an Amiga build directory in `builds/amiga'.
+
+
+======================================================================
+
+CHANGES BETWEEN 2.0.4 and 2.0.3
+
+  - Fixed a rather annoying bug that was introduced in 2.0.3.  Namely,
+    the font  transformation set through  FT_Set_Transform was applied
+    twice to auto-hinted glyphs, resulting in incorrectly rotated text
+    output.
+
+  - Fixed _many_  compiler warnings.   FT2 should now  compile cleanly
+    with Visual  C++'s most pedantic warning level  (/W4).  It already
+    compiled fine with GCC and a few other compilers.
+
+  - Fixed a bug  that prevented the linear advance  width of composite
+    TrueType glyphs to be correctly returned.
+
+  - Fixed    the    Visual    C++    project    files    located    in
+    `builds/win32/visualc' (previous versions  used older names of the
+    library).
+
+  - Many  32-bit constants  have an  `L' appended  to their  value, in
+    order to improve the 16-bitness  of the code.  Someone is actually
+    trying to use FT2 on an Atari ST machine!
+
+  - Updated  the  `builds/detect.mk' file  in  order to  automatically
+    build FT2  on AIX systems.   AIX uses `/usr/sbin/init'  instead of
+    `/sbin/init' and wasn't previously  detected as a Unix platform by
+    the FreeType build system.
+
+  - Updated  the  Unix-specific  portions  of the  build  system  (new
+    libtool version, etc.).
+
+  - The  SFNT kerning  loader now  ensures  that the  table is  sorted
+    (since some problem fonts do not meet this requirement).
+
+
+=======================================================================
+
+CHANGES BETWEEN 2.0.3 and 2.0.2
+
+  I. CHANGES TO THE MODULES / FONT DRIVERS
+
+    - THE  AUTO-HINTER HAS  BEEN SLIGHTLY  IMPROVED, in  order  to fix
+      several annoying artefacts, mainly:
+
+        - Blue  zone alignment  of  horizontal stems  wasn't performed
+          correctly, resulting in artefacts  like the `d' being placed
+          one pixel below the `b' in some fonts like Time New Roman.
+
+        - Overshoot thresholding  wasn't performed correctly, creating
+          unpleasant artefacts at large character pixel sizes.
+
+        - Composite glyph loading has  been simplified.  This gets rid
+          of  various artefacts  where the  components of  a composite
+          glyphs were not correctly spaced.
+
+      These are  the last changes to the  current auto-hinting module.
+      A new  hinting sub-system is currently  in the work  in order to
+      support native hints  in Type 1 / CFF /  OpenType fonts, as well
+      as globally improve rendering.
+
+    - The  PCF  driver has  been  fixed.   It  reported invalid  glyph
+      dimensions for the fonts available on Solaris.
+
+    - The Type  1, CID and CFF  drivers have been modified  to fix the
+      computation of the EM size.
+
+    - The Type 1  driver has been fixed to avoid  a dangerous bug that
+      crashed the library with non-conforming fonts (i.e. ones that do
+      not place the .notdef glyph at position 0).
+
+    - The TrueType  driver had a  rather subtle bug  (dangling pointer
+      when loading  composite glyphs) that could crash  the library in
+      rare occasions!
+
+
+  II. HIGH-LEVEL API CHANGES
+
+    - The error  code enumeration values have been  changed.  An error
+      value  is decomposed  in  a  generic error  code,  and a  module
+      number.  see <freetype/fterrors.h> for details.
+
+    - A   new  public   header   file  has   been  introduced,   named
+      FT_TRIGONOMETRY_H    (include/freetype/fttrigon.h),    providing
+      trigonometric functions to  compute sines, cosines, arctangents,
+      etc. with 16.16 fixed precision.  The implementation is based on
+      the CORDIC  algorithm and is very fast  while being sufficiently
+      accurate.
+
+
+  III. INTERNALS
+
+    - Added  BeOS-specific files  in the  old build  sub-system.  Note
+      that no changes were required to compile the library with Jam.
+
+    - The  configuration  is now  capable  of automatically  detecting
+      64-bit integers  on a set  of predefined compilers  (GCC, Visual
+      C++, Borland C++) and will use them by default.  This provides a
+      small performance boost.
+
+    - A  small memory leak  that happened  when opening  0-sized files
+      (duh!)  have been fixed.
+
+    - Fixed bezier  stack depth  bug in the  routines provided  by the
+      FT_BBOX_H  header   file.   Also  fixed  similar   bugs  in  the
+      rasterizers.
+
+    - The outline bounding  box code has been rewritten  to use direct
+      computations,  instead of  bezier sub-division,  to  compute the
+      exact bounding box of glyphs.   This is slightly slower but more
+      accurate.
+
+    - The build system has been  improved and fixed, mainly to support
+      `make'  on Windows  2000  correctly, avoid  problems with  `make
+      distclean' on non Unix systems, etc.
+
+    - Hexadecimal  constants  have been  suffixed  with  `U' to  avoid
+      problems with certain compilers on 64-bit platforms.
+
+    - A new directory named `src/tools' has been created.  It contains
+      Python scripts and simple unit test programs used to develop the
+      library.
+
+    - The DocMaker tool has been  moved from `docs' to `src/tools' and
+      has been updated with the following:
+
+         - Now accepts the `--title=XXXX' or `-t XXXX' option from the
+           command line to set the project's name in the generated API
+           reference.
+
+         - Now accepts the `--output=DIR'  or `-o DIR' option from the
+           command line to set  the output directory for all generated
+           HTML files.
+
+         - Now accepts the `--prefix=XXXX' or `-p XXX' option from the
+           command  line  to  set  the  file prefix  to  use  for  all
+           generated HTML files.
+
+         - Now generates the current  time/data on each generated page
+           in order to distinguish between versions.
+
+      DocMaker  can be  used with  other  projects now,  not only  FT2
+      (e.g. MLib, FTLayout, etc.).
+
+
+======================================================================
+
+CHANGES BETWEEN 2.0.2 and 2.0.1
+
+  I. CHANGES TO THE MODULES / FONT DRIVERS
+
+    - THE TRUETYPE BYTECODE INTERPRETER IS NOW TURNED OFF, in order to
+      avoid legal problems  with the Apple patents.  It  seems that we
+      mistakenly  turned this option  on in  previous releases  of the
+      build.
+
+      Note that if  you want to use the  bytecode interpreter in order
+      to get high-quality TrueType  rendering, you will need to toggle
+      by        hand        the        definition        of        the
+      TT_CONFIG_OPTION_BYTECODE_INTERPRETER   macro    in   the   file
+      `include/freetype/config/ftoption.h'.
+
+    - The CFF driver has been improved by Tom Kacvinsky and Sander van
+      der Wal:
+
+      * Support for `seac' emulation.
+      * Support for `dotsection'.
+      * Support for retrieving glyph names through
+        `FT_Get_Glyph_Name'.
+
+      The first two items are necessary to correctly a large number of
+      Type 1 fonts converted to the CFF formats by Adobe Acrobat.
+
+    - The Type 1 driver was also improved by Tom & others:
+
+      * Better EM size computation.
+      * Better support for synthetic (transformed) fonts.
+      * The  Type 1  driver returns  the charstrings  corresponding to
+        each glyph in the  `glyph->control_data' field after a call to
+        `FT_Load_Glyph' (thanks Ha Shao).
+
+    - Various other bugfixes, including the following:
+
+      * Fixed a nasty memory leak in the Type 1 driver.
+      * The autohinter  and the pcf  driver used static  writable data
+        when they shouldn't.
+      * Many casts were added to  make the code more 64-bits safe.  It
+        also now compiles on Windows XP 64-bits without warnings.
+      * Some incorrect writable statics were removed in the `autohint'
+        and `pcf' drivers.  FreeType 2 now compiles on Epoc again.
+
+
+  II. CHANGES TO THE HIGH-LEVEL API
+
+    - The library header files inclusion scheme has been changed.  The
+      old scheme looked like:
+
+        #include <freetype/freetype.h>
+        #include <freetype/ftglyph.h>
+        #include <freetype/ftcache.h>
+        #include <freetype/cache/ftimage.h>
+
+      Now you should use:
+
+        #include <ft2build.h>
+        #include FT_FREETYPE_H
+        #include FT_GLYPH_H
+        #include FT_CACHE_H
+        #include FT_CACHE_IMAGE_H
+
+      NOTE THAT  THE OLD  INCLUSION SCHEME WILL  STILL WORK  WITH THIS
+      RELEASE.  HOWEVER, WE  DO NOT GUARANTEE THAT THIS  WILL STILL BE
+      TRUE IN THE NEXT ONE (A.K.A. FREETYPE 2.1).
+
+      The  file <ft2build.h>  is used  to define  the  header filename
+      macros.  The complete and  commented list of macros is available
+      in the API reference under the section name `Header File Macros'
+      in Chapter I.
+
+      For more information, see section I of the following document:
+
+        https://www.freetype.org/freetype2/docs/tutorial/step1.html
+
+    - Many, many comments have been added to the public source file in
+      order to  automatically generate  the API Reference  through the
+      `docmaker.py' Python script.
+
+      The latter has been updated  to support the grouping of sections
+      in chapters and better index sort.  See:
+
+        https://www.freetype.org/freetype2/docs/reference/ft2-toc.html
+
+
+  III. CHANGES TO THE BUILD PROCESS
+
+    - If you  are not  building FreeType 2  with its own  build system
+      (but with your own Makefiles or project files), you will need to
+      be  aware that  the  build  process has  changed  a little  bit.
+
+      You don't  need to put the  `src' directory in  the include path
+      when  compiling  any FT2  component.   Instead,  simply put  the
+      component's directory in the current include path.
+
+      So, if you were doing something like:
+
+        cc -c -Iinclude -Isrc src/base/ftbase.c
+
+      change the line to:
+
+        cc -c -Iinclude -Isrc/base src/base/ftbase.c
+
+      If you were doing something like:
+
+        cd src/base
+        cc -c -I../../include -I.. ftbase.c
+
+      change it to:
+
+        cd src/base
+        cc -c -I../../include ftbase.c
+
+
+======================================================================
+
+CHANGES BETWEEN 2.0.1 and 2.0
+
+  2.0.1 introduces a few changes:
+
+    - Fixed many bugs related to  the support of CFF / OpenType fonts.
+      These  formats are  now much  better supported  though  there is
+      still work planned to  deal with charset tables and PDF-embedded
+      CFF files that use the old `seac' command.
+
+    - The  library could not  be compiled  in debug  mode with  a very
+      small  number   of  C  compilers   whose  pre-processors  didn't
+      implement the `##'  directive correctly (i.e. per se  the ANSI C
+      specification!)  An elegant fix was found.
+
+    - Added  support for  the  free Borland  command-line C++  Builder
+      compiler.   Use `make  setup bcc32'.   Also fixed  a  few source
+      lines that generated new warnings with BCC32.
+
+    - Fixed a bug in FT_Outline_Get_BBox when computing the extrema of
+      a conic Bezier arc.
+
+    - Updated the INSTALL file to add IDE compilation.
+
+    - Other  minor bug  fixes,  from  invalid Type  1  style flags  to
+      correct   support   of  synthetic   (obliqued)   fonts  in   the
+      auto-hinter, better support for embedded bitmaps in a SFNT font.
+
+    - Fixed some problems with `freetype-config'.
+
+  Finally, the `standard' scheme for including FreeType headers is now
+  gradually changing,  but this will  be explained in a  later release
+  (probably 2.0.2).
+
+  And very  special thanks to Tom Kacvinsky  and YAMANO-UCHI Hidetoshi
+  for their contributions!
+
+
+======================================================================
+
+CHANGES BETWEEN beta8 and 2.0
+
+  - Changed  the default  installation  path for  public headers  from
+    `include/freetype' to `include/freetype2'.
+
+    Also added a new `freetype-config' that is automatically generated
+    and installed  on Unix and  Cygwin systems.  The script  itself is
+    used to retrieve the current  install path, C compilation flags as
+    well as linker flags.
+
+  - Fixed several small bugs:
+
+    * Incorrect max advance width for fixed-pitch Type 1 fonts.
+    * Incorrect glyph names for certain TrueType fonts.
+    * The  glyph advance  was not  copied when  FT_Glyph_To_Bitmap was
+      called.
+    * The  linearHoriAdvance  and  linearVertAdvance  fields  were not
+      correctly returned for glyphs processed by the auto-hinter.
+    * `type1z'  renamed back to  `type1'; the  old `type1'  module has
+      been removed.
+
+  - Revamped the  build system  to make it  a lot more  generic.  This
+    will  allow us  to  re-use  nearly un-modified  in  lots of  other
+    projects (including FreeType Layout).
+
+  - Changed `cid' to use `psaux' too.
+
+  - Added the  cache sub-system.  See <freetype/ftcache.h>  as well as
+    the sources  in `src/cache'.  Note  that it compiles but  is still
+    untested for now.
+
+  - Updated `docs/docmaker.py', a draft  API reference is available at
+    https://web.archive.org/web/20001215173400/http://www.freetype.org:80/ft2api.html.
+
+  - Changed `type1' to use `psaux'.
+
+  - Created a  new module named  `psaux' to hold  the Type 1 &  Type 2
+    parsing routines.  It should be  used by `type1', `cid', and `cff'
+    in the future.
+
+  - Fixed an important bug in `FT_Glyph_Get_CBox'.
+
+  - Fixed  some compiler  warnings  that happened  since the  TrueType
+    bytecode decoder was deactivated by default.
+
+  - Fixed two memory leaks:
+
+    * The    memory   manager   (16    bytes)   isn't    released   in
+      FT_Done_FreeType!
+    * Using custom input streams, the  copy of the original stream was
+      never released.
+
+  - Fixed the  auto-hinter by performing automatic  computation of the
+    `filling direction' of each glyph.   This is done through a simple
+    and  fast approximation, and  seems to  work (problems  spotted by
+    Werner though).  The Arphic fonts are a lot nicer though there are
+    still a lot of things to do to handle Asian fonts correctly.
+
+
+======================================================================
+
+BETA-8 (RELEASE CANDIDATE) CHANGES
+
+  - Deactivated the TrueType bytecode interpreter by default.
+
+  - Deactivated the `src/type1' font driver.  Now `src/type1z' is used
+    by default.
+
+  - Updates to the build system.  We now compile the library correctly
+    under  Unix  system  through  `configure' which  is  automatically
+    called on the first `make' invocation.
+
+  - Added the auto-hinting module!  Fixing some bugs here and there.
+
+  - Found some bugs in the  composite loader (seac) of the Type1-based
+    font drivers.
+
+  - Renamed the directory `freetype2/config' to `freetype2/builds' and
+    updated all relevant files.
+
+  - Found a memory leak in the `type1' driver.
+
+  - Incorporated Tom's patches to  support flex operators correctly in
+    OpenType/CFF fonts.  Now all I need is to support pure CFF and CEF
+    fonts to be done with this driver :-)
+
+  - Added the  Windows FNT/FON driver in `src/winfonts'.   For now, it
+    always  `simulates'   a  Unicode  charmap,  so   it  shouldn't  be
+    considered completed right now.
+
+    It  is there  to be  more a  proof of  concept than  anything else
+    anyway.  The driver is a single  C source file, that compiles to 3
+    Kb of code.
+
+    I'm  still working on  the PCF/BDF  drivers, but  I'm too  lazy to
+    finish them now.
+
+  - CHANGES TO THE HIGH-LEVEL API
+
+    * FT_Get_Kerning has a new parameter that allows you to select the
+      coordinates of the kerning  vector (font units, scaled, scaled +
+      grid-fitted).
+    * The  outline functions are  now in <freetype/ftoutln.h>  and not
+      part of <freetype/freetype.h> anymore.
+    * <freetype/ftmodule.h>    now     contains    declarations    for
+       FT_New_Library, FT_Done_Library, FT_Add_Default_Modules.
+    * The so-called convenience  functions have moved from `ftoutln.c'
+      to  `ftglyph.c',  and  are  thus available  with  this  optional
+      component    of   the   library.     They   are    declared   in
+      <freetype/ftglyph.h> now.
+    * Anti-aliased  rendering is now  the default  for FT_Render_Glyph
+      (i.e. corresponds to render_mode == 0 == ft_render_mode_normal).
+      To generate a monochrome bitmap, use ft_render_mode_mono, or the
+      FT_LOAD_MONOCHROME     flag    in    FT_Load_Glyph/FT_Load_Char.
+      FT_LOAD_ANTI_ALIAS is still defined, but values to 0.
+    * <freetype/freetype.h>  now include <freetype/config/ftconfig.h>,
+      solving a few headaches :-)
+    * The type FT_GlyphSlotRec has now a `library' field.
+
+  - CHANGES TO THE `ftglyph.h' API
+
+    This API has  been severely modified in order  to make it simpler,
+    clearer, and more  efficient.  It certainly now looks  like a real
+    `glyph factory'  object, and allows client  applications to manage
+    (i.e.  transform,  bbox  and  render) glyph  images  without  ever
+    knowing their original format.
+
+  - Added  support  for CID-keyed  fonts  to  the  CFF driver.   Maybe
+    support for pure CFF + CEF fonts should come in?
+
+  - Cleaned up  source code in order  to avoid two  functions with the
+    same name.  Also  changed the names of the  files in `type1z' from
+    `t1XXXX' to `z1XXXX' in order to avoid any conflicts.
+
+    `make multi' now works well :-)
+
+    Also removed the use of `cidafm' for now, even if the source files
+    are  still there.  This  functionality will  certainly  go into  a
+    specific module.
+
+  - ADDED SUPPORT FOR THE AUTO-HINTER
+
+    It  works :-) I  have a  demo program  which simply  is a  copy of
+    `ftview'       that      does       a      `FT_Add_Module(library,
+    &autohinter_module_class)' after  library initialization, and Type
+    1 & OpenType/CFF fonts are now hinted.
+
+    CID  fonts are  not hinted,  as they  include no  charmap  and the
+    auto-hinter doesn't include  `generic' global metrics computations
+    yet.
+
+    Now, I need to release this thing to the FreeType 2 source.
+
+  - CHANGES TO THE RENDERER MODULES
+
+    The  monochrome  and smooth  renderers  are  now  in two  distinct
+    directories, namely `src/raster1' and `src/smooth'.  Note that the
+    old `src/renderer' is now gone.
+
+    I ditched  the 5-gray-levels renderers.  Basically,  it involved a
+    simple #define toggle in 'src/raster1/ftraster.c'.
+
+    FT_Render_Glyph,  FT_Outline_Render  &  FT_Outline_Get_Bitmap  now
+    select the best renderer  available, depending on render mode.  If
+    the current renderer for a  given glyph image format isn't capable
+    of supporting  the render mode, another  one will be  found in the
+    library's list.   This means that client applications  do not need
+    to  switch or  set  the  renderers themselves  (as  in the  latest
+    change), they'll get what they want automatically.  At last.
+
+    Changed the demo programs accordingly.
+
+  - MAJOR INTERNAL REDESIGN:
+
+    A lot of internal modifications  have been performed lately on the
+    source in order to provide the following enhancements:
+
+    * More generic module support:
+
+      The FT_Module  type is  now defined to  represent a handle  to a
+      given  module.   The  file  <freetype/ftmodule.h>  contains  the
+      FT_Module_Class definition, as well as the module-loading public
+      API.
+
+      The  FT_Driver type  is still  defined, and  still  represents a
+      pointer to  a font driver.  Note that  FT_Add_Driver is replaced
+      by FT_Add_Module, FT_Get_Driver by FT_Get_Module, etc.
+
+    * Support for generic glyph image types:
+
+      The FT_Renderer  type is a pointer  to a module  used to perform
+      various operations on glyph image.
+
+      Each renderer is  capable of handling images in  a single format
+      (e.g. ft_glyph_format_outline).  Its functions are used to:
+
+      - transform an glyph image
+      - render a glyph image into a bitmap
+      - return the control box (dimensions) of a given glyph image
+
+      The scan converters `ftraster.c' and `ftgrays.c' have been moved
+      to the new directory `src/renderer', and are used to provide two
+      default renderer modules.
+
+      One corresponds  to the `standard' scan-converter,  the other to
+      the `smooth' one.
+
+      he  current  renderer  can  be  set  through  the  new  function
+      FT_Set_Renderer.
+
+      The old raster-related function FT_Set_Raster, FT_Get_Raster and
+      FT_Set_Raster_Mode have now disappeared, in favor of the new:
+
+        FT_Get_Renderer
+        FT_Set_Renderer
+
+      See the file <freetype/ftrender.h> for more details.
+
+      These  changes  were  necessary  to properly  support  different
+      scalable formats in the future, like bi-color glyphs, etc.
+
+    * Glyph loader object:
+
+      A  new  internal  object,  called  a  'glyph  loader'  has  been
+      introduced in the base layer.  It is used by all scalable format
+      font drivers to load glyphs and composites.
+
+      This object  has been  created to reduce  the code size  of each
+      driver,  as  each  one  of  them  basically  re-implemented  its
+      functionality.
+
+      See <freetype/internal/ftobjs.h> and the FT_GlyphLoader type for
+      more information.
+
+    * FT_GlyphSlot has new fields:
+
+      In  order   to  support  extended  features   (see  below),  the
+      FT_GlyphSlot structure has a few new fields:
+
+      linearHoriAdvance:
+
+        This  field  gives  the   linearly  scaled  (i.e.  scaled  but
+        unhinted) advance  width for the  glyph, expressed as  a 16.16
+        fixed pixel value.  This is useful to perform WYSIWYG text.
+
+      linearVertAdvance:
+        This field  gives the linearly  scaled advance height  for the
+        glyph  (relevant in  vertical  glyph layouts  only).  This  is
+        useful to perform WYSIWYG text.
+
+        Note that  the two above field replace  the removed `metrics2'
+        field in the glyph slot.
+
+      advance:
+        This field is a vector  that gives the transformed advance for
+        the glyph.   By default, it corresponds to  the advance width,
+        unless  FT_LOAD_VERTICAL_LAYOUT  was  specified  when  calling
+        FT_Load_Glyph or FT_Load_Char.
+
+      bitmap_left:
+        This  field gives  the  distance in  integer  pixels from  the
+        current pen position  to the left-most pixel of  a glyph image
+        IF IT IS  A BITMAP.  It is only valid  when the `format' field
+        is set to `ft_glyph_format_bitmap', for example, after calling
+        the new function FT_Render_Glyph.
+
+      bitmap_top:
+        This  field gives  the  distance in  integer  pixels from  the
+        current pen position (located on the baseline) to the top-most
+        pixel of the  glyph image IF IT IS  A BITMAP.  Positive values
+        correspond to upwards Y.
+
+      loader:
+        This  is a  new  private  field for  the  glyph slot.   Client
+        applications should not touch it.
+
+
+    * Support for transforms and direct rendering in FT_Load_Glyph:
+
+      Most of the functionality found in <freetype/ftglyph.h> has been
+      moved to the core library.  Hence, the following:
+
+      - A   transform   can   be   specified  for   a   face   through
+        FT_Set_Transform.  this transform  is applied by FT_Load_Glyph
+        to  scalable glyph  images (i.e.  NOT TO  BITMAPS)  before the
+        function returns, unless the bit flag FT_LOAD_IGNORE_TRANSFORM
+        was set in the load flags.
+
+      - Once  a  glyph image  has  been  loaded,  it can  be  directly
+        converted  to  a  bitmap  by  using  the  new  FT_Render_Glyph
+        function.  Note that this  function takes the glyph image from
+        the glyph slot,  and converts it to a  bitmap whose properties
+        are returned  in `face.glyph.bitmap', `face.glyph.bitmap_left'
+        and `face.glyph.bitmap_top'.  The  original native image might
+        be lost after the conversion.
+
+      - When using the new  bit flag FT_LOAD_RENDER, the FT_Load_Glyph
+        and   FT_Load_Char   functions   will   call   FT_Render_Glyph
+        automatically when needed.
+
+  - Reformatted all  modules source  code in order  to get rid  of the
+    basic data types redefinitions (i.e. `TT_Int' instead of `FT_Int',
+    `T1_Fixed'  instead  of  `FT_Fixed').  Hence  the  format-specific
+    prefixes like  `TT_', `T1_',  `T2_' and `CID_'  are only  used for
+    relevant structures.
+
+
+======================================================================
+
+OLD CHANGES FOR BETA 7
+
+  - bug-fixed the  OpenType/CFF parser.  It  now loads and displays my
+    two  fonts nicely,  but I'm  pretty certain  that more  testing is
+    needed :-)
+
+  - fixed the crummy Type 1 hinter, it now handles accented characters
+    correctly (well, the accent is  not always well placed, but that's
+    another problem..)
+
+  - added the CID-keyed Type 1 driver in `src/cid'.  Works pretty well
+    for only 13 Kb of code  ;-) Doesn't read AFM files though, nor the
+    really useful CMAP files..
+
+  - fixed  two  bugs  in  the  smooth  renderer  (src/base/ftgrays.c).
+    Thanks to Boris Letocha for spotting them and providing a fix.
+
+  - fixed potential `divide by zero' bugs in ftcalc.c.
+
+  - added source  code for  the OpenType/CFF driver  (still incomplete
+    though..)
+
+  - modified the  SFNT driver slightly  to perform more  robust header
+    checks  in TT_Load_SFNT_Header.  This prevents certain  font files
+    (e.g.  some  Type  1  Multiple  Masters)  from  being  incorrectly
+    `recognized' as TrueType font files..
+
+  - moved a lot of stuff from  the TrueType driver to the SFNT module,
+    this   allows   greater   code   re-use   between   font   drivers
+    (e.g. TrueType, OpenType, Compact-TrueType, etc..)
+
+  - added a tiny segment cache to the SFNT Charmap 4 decoder, in order
+    to minimally speed it up..
+
+  - added  support for  Multiple Master  fonts in  `type1z'.  There is
+    also a new file named <freetype/ftmm.h> which defines functions to
+    manage them from client applications.
+
+    The new file `src/base/ftmm.c' is also optional to the engine..
+
+  - various  formatting changes (e.g.  EXPORT_DEF ->  FT_EXPORT_DEF) +
+    small bug fixes in FT_Load_Glyph, the `type1' driver, etc..
+
+  - a minor fix to the Type 1 driver to let them apply the font matrix
+    correctly (used for many oblique fonts..)
+
+  - some fixes for 64-bit systems (mainly changing some FT_TRACE calls
+    to use %p instead of %lx).  Thanks to Karl Robillard.
+
+  - fixed  some bugs  in  the sbit  loader (src/base/sfnt/ttsbit.c)  +
+    added  a new flag,  FT_LOAD_CROP_BITMAP to  query that  bitmaps be
+    cropped when  loaded from a file  (maybe I should  move the bitmap
+    cropper to the base layer ??).
+
+  - changed the default  number of gray levels of  the smooth renderer
+    to 256  (instead of  the previous 128).  Of course, the  human eye
+    can't see any difference ;-)
+
+  - removed TT_MAX_SUBGLYPHS,  there is no static limit  on the number
+    of subglyphs in a TrueType font now..
+
+
+======================================================================
+
+OLD CHANGES 16 May 2000
+
+  - tagged `BETA-6'  in the  CVS tree.  This one is a  serious release
+    candidate even though it doesn't incorporate the auto-hinter yet..
+
+  - various obsolete files were removed, and copyright header updated
+
+  - finally  updated  the  standard   raster  to  fix  the  monochrome
+    rendering bug + re-enable  support for 5-gray levels anti-aliasing
+    (suck, suck..)
+
+  - created new header files, and modified sources accordingly:
+
+     <freetype/fttypes.h>
+       - simple FreeType types, without the API
+     <freetype/internal/ftmemory.h>
+       - definition of memory-management macros
+
+  - added   the   `DSIG'   (OpenType   Digital   Signature)   tag   to
+    <freetype/tttags.h>
+
+  - light update/cleaning of the build system + changes to the sources
+    in  order  to  get  rid  of _all_  compiler  warnings  with  three
+    compilers, i.e:
+
+    gcc with `-ansi -pedantic -Wall -W', Visual C++ with `/W3 /WX' and
+    LCC
+
+    IMPORTANT NOTE FOR WIN32-LCC USERS:
+    |
+    |  It seems the C pre-processor  that comes with LCC is broken, it
+    |  doesn't  recognize  the  ANSI  standard  directives  #  and  ##
+    |  correctly   when  one  of   the  argument  is  a  macro.  Also,
+    |  something like:
+    |
+    |     #define F(x)  print##x
+    |
+    |     F(("hello"))
+    |
+    |  will get incorrectly translated to:
+    |
+    |     print "hello")
+    |
+    |  by its pre-processor.  For this reason, you simply cannot build
+    |  FreeType 2 in debug mode with this compiler..
+
+  - yet  another massive grunt work.  I've  changed the  definition of
+    the EXPORT_DEF,  EXPORT_FUNC, BASE_DEF &  BASE_FUNC macros.  These
+    now take an argument, which is the function's return value type.
+
+    This  is necessary to  compile FreeType  as a  DLL on  Windows and
+    OS/2.  Depending on the compiler used, a compiler-specific keyword
+    like  __export or __system  must be  placed before  (VisualC++) or
+    after (BorlandC++) the type..
+
+    Of course, this needed a lot of changes throughout the source code
+    to make it compile again...  All cleaned up now, apparently..
+
+    Note also  that there is a  new EXPORT_VAR macro  defined to allow
+    the   _declaration_    of   an   exportable    public   (constant)
+    variable.  This  is  the   case  of  the  raster  interfaces  (see
+    ftraster.h and ftgrays.h), as well as each module's interface (see
+    sfdriver.h, psdriver.h, etc..)
+
+  - new feature: it  is now possible to pass  extra parameters to font
+                 drivers  when creating  a new  face object.  For now,
+                 this capability is unused.  It could however prove to
+                 be useful in a near future..
+
+      the FT_Open_Args structure was  changes, as well as the internal
+      driver interface  (the specific `init_face'  module function has
+      now a different signature).
+
+  - updated the tutorial (not finished though).
+
+  - updated the top-level BUILD  document
+
+  - fixed  a  potential memory  leak  that  could  occur when  loading
+    embedded bitmaps.
+
+  - added     the     declaration     of     FT_New_Memory_Face     in
+    <freetype/freetype.h>, as  it was  missing from the  public header
+    (the implementation was already in `ftobjs.c').
+
+  - the file <freetype/fterrors.h> has been seriously updated in order
+    to allow  the automatic generation  of error message tables.   See
+    the comments within it for more information.
+
+  - major directory  hierarchy re-organisation.  This was done for two
+    things:
+
+      * first,  to ease  the `manual'  compilation of  the  library by
+        requiring at lot less include paths :-)
+
+      * second,  to  allow  external  programs to  effectively  access
+        internal  data  fields.  For example,  this  can be  extremely
+        useful if  someone wants  to write a  font producer or  a font
+        manager on top of FreeType.
+
+    Basically, you  should now use  the 'freetype/' prefix  for header
+    inclusion, as in:
+
+        #include <freetype/freetype.h>
+        #include <freetype/ftglyph.h>
+
+    Some new include sub-directories are available:
+
+     a. the  `freetype/config' directory,  contains two files  used to
+        configure  the  build  of  the  library.  Client  applications
+        should  not need  to look  at these  normally, but they can if
+        they want.
+
+        #include <freetype/config/ftoption.h>
+        #include <freetype/config/ftconfig.h>
+
+     b. the `freetype/internal'  directory, contains header files that
+        describes library  internals.  These are the header files that
+        were  previously  found  in  the `src/base'  and  `src/shared'
+        directories.
+
+
+    As  usual, the build  system and  the demos  have been  updated to
+    reflect the change..
+
+    Here's a layout of the new directory hierarchy:
+
+    TOP_DIR
+      include/
+         freetype/
+            freetype.h
+            ...
+            config/
+              ftoption.h
+              ftconfig.h
+              ftmodule.h
+
+            internal/
+              ftobjs.h
+              ftstream.h
+              ftcalc.h
+              ...
+
+      src/
+         base/
+            ...
+
+         sfnt/
+         psnames/
+         truetype/
+         type1/
+         type1z/
+
+
+    Compiling a module is now  much easier, for example, the following
+    should work when in the TOP_DIR directory on an ANSI build:
+
+       gcc -c -I./include -I./src/base src/base/ftbase.c
+       gcc -c -I./include -I./src/sfnt src/sfnt/sfnt.c
+       etc..
+
+    (of course, using -Iconfig/<system> if you provide system-specific
+     configuration files).
+
+  - updated the structure of FT_Outline_Funcs in order to allow direct
+    coordinate scaling within  the outline decomposition routine (this
+    is  important for virtual  `on' points  with TrueType  outlines) +
+    updates to the rasters to support this..
+
+  - updated  the OS/2  table  loading code  in `src/sfnt/ttload.c'  in
+    order to support version 2 of the table (see OpenType 1.2 spec)
+
+  - created  `include/tttables.h'  and  `include/t1tables.h' to  allow
+    client applications to access some of  the SFNT and T1 tables of a
+    face  with  a  procedural  interface (see  `FT_Get_Sfnt_Table')  +
+    updates to internal source files to reflect the change..
+
+  - some  cleanups in  the source  code to  get rid  of  warnings when
+    compiling with the `-Wall -W -ansi -pedantic' options in gcc.
+
+  - debugged and moved the smooth renderer to `src/base/ftgrays.c' and
+    its header to `include/ftgrays.h'
+
+  - updated TT_MAX_SUBGLYPHS  to 96 as some CJK  fonts have composites
+    with up to 80 sub-glyphs !! Thanks to Werner
+
+
+======================================================================
+
+OLD CHANGES - 14-apr-2000
+
+  - fixed  a bug  in  the  TrueType glyph  loader  that prevented  the
+    correct loading of some CJK glyphs in mingli.ttf
+
+  - improved the standard Type 1 hinter in `src/type1'
+
+  - fixed two bugs  in the experimental Type 1  driver in `src/type1z'
+    to handle the new XFree86 4.0 fonts (and a few other ones..)
+
+  - the smooth  renderer is now  complete and supports  sub-banding to
+    render large glyphs  at high speed.  However, it is still  located
+    in `demos/src/ftgrays.c' and should move to the  library itself in
+    the next  beta.  NOTE: The  smooth  renderer  doesn't  compile  in
+    stand-alone mode anymore, but this should be fixed RSN..
+
+  - introduced convenience  functions to  more easily deal  with glyph
+    images, see  `include/ftglyph.h' for more details, as  well as the
+    new  demo program  named `demos/src/ftstring.c'  that demonstrates
+    its use
+
+  - implemented  FT_LOAD_NO_RECURSE in  both the  TrueType and  Type 1
+    drivers  (this  is required  by  the  auto-hinter  to improve  its
+    results).
+
+  - changed   the  raster   interface,  in   order  to   allow  client
+    applications  to   provide  their   own  span-drawing   callbacks.
+    However,   only   the   smooth   renderer   supports   this.   See
+    `FT_Raster_Params' in the file `include/ftimage.h'.
+
+  - fixed  a small bug  in FT_MulFix  that caused  incorrect transform
+    computation!
+
+  - Note: The tutorial is out-of-date.
+
+
+======================================================================
+
+OLD CHANGES - 12-mar-2000
+
+  - changed  the  layout  of  configuration  files  :  now,  all  ANSI
+    configuration         files         are         located         in
+    `freetype2/config'.  System-specific over-rides  can be  placed in
+    `freetype2/config/<system>'.
+
+  - moved all configuration macros to `config/ftoption.h'
+
+  - improvements in the Type 1 driver with AFM support
+
+  - changed the fields  in the FT_Outline structure :  the old `flags'
+    array is re-named `tags', while all ancient flags are encoded into
+    a single unsigned int named `flags'.
+
+  - introduced     new      flags     in     FT_Outline.flags     (see
+    ft_outline_.... enums in `ftimage.h').
+
+  - changed outline functions to `FT_Outline_<action>' syntax
+
+  - added a smooth anti-alias renderer to the demonstration programs
+
+  - added Mac graphics driver (thanks Just)
+
+  - FT_Open_Face  changed  in  order   to  received  a  pointer  to  a
+    FT_Open_Args descriptor..
+
+  - various  cleanups,  a  few  more API  functions  implemented  (see
+    FT_Attach_File)
+
+  - updated some docs
+
+
+======================================================================
+
+OLD CHANGES - 22-feb-2000
+
+  - introduced the `psnames' module.  It is used to:
+
+      o convert  a Postscript glyph  name into the  equivalent Unicode
+        character code (used by the  Type 1 driver(s) to synthesize on
+        the fly a Unicode charmap).
+
+      o provide an  interface to retrieve the Postscript  names of the
+        Macintosh,  Adobe  Standard &  Adobe  Expert character  codes.
+        (the Macintosh  names are  used by the  SFNT-module postscript
+        names support routines, while the other two tables are used by
+        the Type 1 driver(s)).
+
+  - introduced the `type1z' alternate Type 1 driver.  This is a (still
+    experimental) driver  for the Type  1 format that  will ultimately
+    replace the one  in `src/type1'.  It uses pattern matching to load
+    data from the font, instead of a finite  state analyzer.  It works
+    much better than the `old' driver with `broken' fonts.  It is also
+    much smaller (under 15 Kb).
+
+  - the  Type 1  drivers (both  in `src/type1'  and  `src/type1z') are
+    nearly  complete.  They  both  provide automatic  Unicode  charmap
+    synthesis through  the `psnames' module.  No re-encoding vector is
+    needed.  (note  that they  still  leak  memory  due to  some  code
+    missing, and I'm getting lazy).
+
+    Trivial AFM support has been added to read kerning information but
+    wasn't exactly tested as it should ;-)
+
+  - The TrueType  glyph loader has  been seriously rewritten  (see the
+    file  `src/truetype/ttgload.c'.  It is now  much, much  simpler as
+    well as  easier to read,  maintain and understand  :-) Preliminary
+    versions introduced a  memory leak that has been  reported by Jack
+    Davis, and is now fixed..
+
+  - introduced  the new  `ft_glyph_format_plotter', used  to represent
+    stroked outlines  like Windows `Vector' fonts, and  certain Type 1
+    fonts  like `Hershey'.  The corresponding  raster will  be written
+    soon.
+
+  - FT_New_Memory_Face  is  gone.  Likewise,  FT_Open_Face has  a  new
+    interface that uses a structure  to describe the input stream, the
+    driver (if required), etc..
+
+
+TODO
+
+  - Write FT_Get_Glyph_Bitmap and FT_Load_Glyph_Bitmap
+
+  - Add a function like FT_Load_Character(face, char_code, load_flags)
+    that  would   really  embed  a  call   to  FT_Get_Char_Index  then
+    FT_Load_Glyph to ease developer's work.
+
+  - Update the tutorial!
+
+  - consider adding  support for Multiple  Master fonts in the  Type 1
+    drivers.
+
+  - Test the AFM routines of the  Type 1 drivers to check that kerning
+    information is returned correctly.
+
+  - write a decent auto-gridding component  !! We need this to release
+    FreeType 2.0 gold !
+
+
+less urgent needs:
+
+  - add a CFF/Type2 driver
+  - add a BDF driver
+  - add a FNT/PCF/HBF driver
+  - add a Speedo driver from the X11 sources
+
+
+======================================================================
+
+OLDER CHANGES - 27-jan-2000
+
+  - updated the  `sfnt' module  interface to allow  several SFNT-based
+    drivers to co-exist peacefully
+
+  - updated  the `T1_Face'  type  to better  separate Postscript  font
+    content  from the  rest of  the FT_Face  structure.  Might be used
+    later by the CFF/Type2 driver..
+
+  - added an experimental replacement Type 1 driver featuring advanced
+    (and speedy) pattern matching to retrieve the data from postscript
+    fonts.
+
+  - very minor  changes in the implementation  of FT_Set_Char_Size and
+    FT_Set_Pixel_Sizes (they now implement default to lighten the font
+    driver's code).
+
+
+======================================================================
+
+OLD MESSAGE
+
+This file summarizes the changes  that occurred  since the last `beta'
+of FreeType 2. Because the list is important, it has been divided into
+separate sections:
+
+Table Of Contents:
+
+    I   High-Level Interface (easier !)
+   II   Directory Structure
+  III   Glyph Image Formats
+   IV   Build System
+    V   Portability
+   VI   Font Drivers
+
+
+----------------------------------------------------------------------
+
+High-Level Interface:
+
+  The high-level API has been considerably simplified.  Here is how:
+
+    - resource objects have disappeared.  this means that face objects
+      can now be created with  a single function call (see FT_New_Face
+      and FT_Open_Face)
+
+    - when calling  either FT_New_Face  & FT_Open_Face, a  size object
+      and a glyph slot object  are automatically created for the face,
+      and can  be accessed  through `face->glyph' and  `face->size' if
+      one really  needs to.   In most cases,  there's no need  to call
+      FT_New_Size or FT_New_Glyph.
+
+    - similarly,  FT_Load_Glyph  now  only  takes  a  `face'  argument
+      (instead  of a  glyph  slot  and a  size).  Also,  its  `result'
+      parameter is  gone, as the glyph  image type is  returned in the
+      field `face->glyph.format'
+
+    - the list  of available  charmaps is directly  accessible through
+      `face->charmaps', counting `face->num_charmaps'  elements.  Each
+      charmap  has an  'encoding'  field which  specifies which  known
+      encoding it deals with.  Valid values are, for example:
+
+          ft_encoding_unicode      (for ASCII, Latin-1 and Unicode)
+          ft_encoding_apple_roman
+          ft_encoding_sjis
+          ft_encoding_adobe_standard
+          ft_encoding_adobe_expert
+
+      other  values may  be added  in the  future.  Each charmap still
+      holds  its `platform_id'  and `encoding_id'  values in  case the
+      encoding is too exotic for the current library
+
+
+----------------------------------------------------------------------
+
+Directory Structure:
+
+  Should seem obvious to most of you:
+
+     freetype/
+         config/        -- configuration sub-makefiles
+            ansi/
+            unix/       -- platform-specific configuration files
+            win32/
+            os2/
+            msdos/
+
+         include/       -- public header  files, those to  be included
+                           directly by client apps
+
+         src/           -- sources of the library
+           base/        -- the base layer
+           sfnt/        -- the sfnt `driver'  (see the drivers section
+                           below)
+           truetype/    -- the truetype driver
+           type1/       -- the type1 driver
+           shared/      -- some header files shared between drivers
+
+         demos/         -- demos/tools
+
+         docs/          -- documentation (a bit empty for now)
+
+
+----------------------------------------------------------------------
+
+Glyph Image Formats:
+
+  Drivers are now able to  register new glyph image formats within the
+  library.  For  now, the  base layer supports  of course  bitmaps and
+  vector  outlines, but  one  could imagine  something different  like
+  colored bitmaps, bi-color vectors or whatever else (Metafonts anyone
+  ??).
+
+  See  the   file  `include/ftimage.h'.   Note  also  that   the  type
+  FT_Raster_Map  is gone,  and  is now  replaced  by FT_Bitmap,  which
+  should encompass all known bitmap types.
+
+  Each new  image format  must provide at  least one `raster',  i.e. a
+  module capable of  transforming the glyph image into a bitmap.  It's
+  also possible  to change the default  raster used for  a given glyph
+  image format.
+
+  The default outline  scan-converter now uses 128 levels  of grays by
+  default,  which tends  to smooth  many  things.  Note that the  demo
+  programs have been updated significantly in order to display these..
+
+
+----------------------------------------------------------------------
+
+Build system:
+
+  You still need  GNU Make to build the library.  The build system has
+  been very seriously re-vamped in order to provide things like :
+
+   - automatic host platform  detection (reverting to 'config/ansi' if
+     it is not detected, with pseudo-standard compilation flags)
+
+   - the ability to compile from the Makefiles with very different and
+     exotic compilers.  Note that linking the library can be difficult
+     for some platforms.
+
+     For example, the file `config/win32/lcclib.bat' is invoked by the
+     build system to create the `.lib' file with LCC-Win32 because its
+     librarian  has too  many flaws  to be  invoked directly  from the
+     Makefile.
+
+  Here's how it works:
+
+  - the first time you type `make',  the build system runs a series of
+    sub-makefiles  in order  to detect  your host  platform.  It  then
+    dumps what it found, and creates a file called `config.mk' in  the
+    current  directory.  This is a  sub-Makefile used  to  define many
+    important Make variables used to build the library.
+
+  - the second time, the build system detects the `config.mk' then use
+    it  to  build the  library.  All object  files  go  into 'obj'  by
+    default,  as well  as the  library file,  but this  can  easily be
+    changed.
+
+  Note that  you can run `make  setup' to force  another host platform
+  detection  even   if  a  `config.mk'  is  present   in  the  current
+  directory.  Another solution  is  simply to  delete  the file,  then
+  re-run make.
+
+  Finally, the  default compiler  for all platforms  is gcc  (for now,
+  this will hopefully changed in the future).  You can however specify
+  a different  compiler by specifying  it after the 'setup'  target as
+  in:
+
+      gnumake setup lcc         on Win32 to use the LCC compiler
+      gnumake setup visualc     on Win32 to use Visual C++
+
+  See  the file  `config/<system>/detect.mk' for  a list  of supported
+  compilers for your platforms.
+
+  It should be relatively easy  to write new detection rules files and
+  config.mk..
+
+  Finally, to  build the demo programs,  go to `demos'  and launch GNU
+  Make, it will use the `config.mk'  in the top directory to build the
+  test programs..
+
+
+----------------------------------------------------------------------
+
+Portability:
+
+  In  the  previous  beta,  a  single FT_System  object  was  used  to
+  encompass  all  low-level  operations like  thread  synchronisation,
+  memory management and i/o access.  This has been greatly simplified:
+
+    - thread synchronisation  has been dropped, for  the simple reason
+      that the library  is already re-entrant, and that  if you really
+      need  two  threads accessing  the  same  FT_Library, you  should
+      really synchronize access to it yourself with a simple mutex.
+
+    - memory  management is  performed  through a  very simple  object
+      called `FT_Memory',  which really is a table  containing a table
+      of pointers to  functions like malloc, realloc and  free as well
+      as some user data (closure).
+
+    - resources have disappeared (they created more problems than they
+      solved), and  i/o management have  been simplified greatly  as a
+      result.  Streams are  defined through  FT_Stream objects,  which
+      can be either memory-based or disk-based.
+
+      Note that  each face  has its own  stream, which is  closed only
+      when  the  face object  is  destroyed.  Hence,  a function  like
+      TT_Flush_Face in 1.x cannot be directly  supported.  However, if
+      you really need something like  this, you can easily tailor your
+      own streams  to achieve the same  feature at a  lower level (and
+      use FT_Open_Face instead of FT_New_Face to create the face).
+
+  See the file  `include/ftsystem.h' for more details, as  well as the
+  implementations found in `config/unix' and `config/ansi'.
+
+
+----------------------------------------------------------------------
+
+Font Drivers:
+
+  The  Font Driver  interface has  been modified  in order  to support
+  extensions & versioning.
+
+
+  The  list of  the font  drivers that  are statically  linked  to the
+  library at compile time is  managed through a new configuration file
+  called `config/<platform>/ftmodule.h'.
+
+  This  file is  autogenerated  when  invoking  `make modules'.   This
+  target  will  parse  all  sub-directories  of  'src', looking  for a
+  `module.mk' rules  file, used  to describe  the driver to  the build
+  system.
+
+  Hence, one  should call  `make modules' each  time a font  driver is
+  added or removed from the `src' directory.
+
+  Finally, this  version  provides  a `pseudo-driver'  in  `src/sfnt'.
+  This  driver  doesn't  support  font  files  directly, but  provides
+  services used by all TrueType-like font drivers.  Hence, its code is
+  shared between  the TrueType & OpenType  font formats,  and possibly
+  more formats to come if we're lucky..
+
+
+----------------------------------------------------------------------
+
+Extensions support:
+
+  The extensions support is inspired by the one found in 1.x.
+
+  Now, each font driver has  its own `extension registry', which lists
+  which extensions  are available  for the font  faces managed  by the
+  driver.
+
+  Extension ids are  now strings, rather than 4-byte  tags, as this is
+  usually more readable.
+
+  Each extension has:
+    - some data, associated to each face object
+    - an interface (table of function pointers)
+
+  An extension  that is format-specific should  simply register itself
+  to the correct font driver.  Here is some example code:
+
+   // Registering an extensions
+   //
+   FT_Error  FT_Init_XXXX_Extension( FT_Library  library )
+   {
+     FT_DriverInterface*  tt_driver;
+
+     driver = FT_Get_Driver( library, "truetype" );
+     if (!driver) return FT_Err_Unimplemented_Feature;
+
+     return FT_Register_Extension( driver, &extension_class );
+   }
+
+
+   // Implementing the extensions
+   //
+   FT_Error  FT_Proceed_Extension_XXX( FT_Face  face )
+   {
+     FT_XXX_Extension            ext;
+     FT_XXX_Extension_Interface  ext_interface;
+
+     ext = FT_Get_Extension( face, "extensionid", &ext_interface );
+     if (!ext) return error;
+
+     return ext_interface->do_it(ext);
+   }
+
+------------------------------------------------------------------------
+
+Copyright (C) 2000-2023 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.
+
+
+Local Variables:
+version-control: never
+coding: utf-8
+End:
+
+--- end of CHANGES ---
diff --git a/contrib/libs/freetype/docs/FTL.TXT b/contrib/libs/freetype/docs/FTL.TXT
new file mode 100644
index 0000000000..c406d150fa
--- /dev/null
+++ b/contrib/libs/freetype/docs/FTL.TXT
@@ -0,0 +1,169 @@
+                    The FreeType Project LICENSE
+                    ----------------------------
+
+                            2006-Jan-27
+
+                    Copyright 1996-2002, 2006 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 © <year> The FreeType
+    Project (www.freetype.org).  All rights reserved.
+   """
+
+  Please replace <year> with the value from the FreeType version you
+  actually use.
+
+
+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@nongnu.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 freetype-devel@nongnu.org
+
+      Discusses bugs,  as well  as engine internals,  design issues,
+      specific licenses, porting, etc.
+
+  Our home page can be found at
+
+    https://www.freetype.org
+
+
+--- end of FTL.TXT ---
diff --git a/contrib/libs/freetype/docs/GPLv2.TXT b/contrib/libs/freetype/docs/GPLv2.TXT
new file mode 100644
index 0000000000..b2fe7b6af3
--- /dev/null
+++ b/contrib/libs/freetype/docs/GPLv2.TXT
@@ -0,0 +1,340 @@
+		    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.
+
+    <one line to give the program's name and a brief idea of what it does.>
+    Copyright (C) <year>  <name of author>
+
+    This program is free software; you can redistribute it and/or modify
+    it under the terms of the GNU General Public License as published by
+    the Free Software Foundation; either version 2 of the License, or
+    (at your option) any later version.
+
+    This program is distributed in the hope that it will be useful,
+    but WITHOUT ANY WARRANTY; without even the implied warranty of
+    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+    GNU General Public License for more details.
+
+    You should have received a copy of the GNU General Public License
+    along with this program; if not, write to the Free Software
+    Foundation, Inc., 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.
+
+  <signature of Ty Coon>, 1 April 1989
+  Ty Coon, President of Vice
+
+This General Public License does not permit incorporating your program into
+proprietary programs.  If your program is a subroutine library, you may
+consider it more useful to permit linking proprietary applications with the
+library.  If this is what you want to do, use the GNU Library General
+Public License instead of this License.
diff --git a/contrib/libs/freetype/docs/INSTALL b/contrib/libs/freetype/docs/INSTALL
new file mode 100644
index 0000000000..49ab112e41
--- /dev/null
+++ b/contrib/libs/freetype/docs/INSTALL
@@ -0,0 +1,114 @@
+
+There are  several ways  to build the  FreeType library,  depending on
+your system and the level of  customization you need.  Here is a short
+overview of the documentation available:
+
+
+I. Prerequisites and dependencies
+=================================
+
+  FreeType is a low level C library  that only depends on the standard
+  C library with very few platform-dependent optimizations utilized at
+  build time.  Any  C99-compliant compiler  should be able  to compile
+  FreeType.  System libraries,  such as  zlib,  Gzip,  bzip2,  Brotli,
+  and libpng,  might  be  used  to handle  compressed fonts  or decode
+  embedded PNG glyphs.
+
+  FreeType  auto-configuration scripts  should be  able to detect  the
+  prerequisites if the necessary headers are available  at the default
+  locations.  Otherwise,  modify  `include/freetype/config/ftoption.h`
+  to control how the FreeType library gets built.  Normally, you don't
+  need to change anything.
+
+  Applications have very limited control over FreeType's behaviour  at
+  run-time;  look at the documentation of function `FT_Property_Set`.
+
+
+II. Normal installation and upgrades
+====================================
+
+  1. Unix and Unix-like systems
+
+    This also includes MacOS, Cygwin, MinGW + MSYS, Mingw-w64 + MSYS2,
+    and possibly other, similar environments.
+
+    Please read `INSTALL.UNIX` to install or upgrade FreeType  2 on  a
+    Unix system.   Note  that  you  *need*  GNU  Make   for  automatic
+    compilation,  since other make tools won't work (this includes BSD
+    Make).
+
+    GNU Make VERSION 3.81 OR NEWER IS NEEDED!
+
+
+  2. Other systems using GNU Make
+
+    On some  non-Unix platforms, it  is possible to build  the library
+    using only  the GNU Make utility.   Note that *NO OTHER  MAKE TOOL
+    WILL  WORK*[1]!   This  methods   supports  several  compilers  on
+    Windows, OS/2, and BeOS,  including MinGW* (without MSYS*), Visual
+    C++, Borland C++, and more.
+
+    Instructions are provided in the file `INSTALL.GNU`.
+
+
+  3. Other build tools and platforms.
+
+    A few other tools  can be used  to build FreeType.  You  can  find
+    the  corresponding instruction files  in  the FreeType root folder
+    or the builds/ sub-folder.
+
+      CMake   :: see `CMakeLists.txt` for more information
+      Meson   :: see `meson.build` for more information
+      MSBuild :: see `builds/windows/vc2010/freetype.vcxproj`
+      MMS     :: see `vms_make.com` and `docs/INSTALL.VMS`
+
+
+  4. With an IDE Project File (e.g., for Visual Studio or CodeWarrior)
+
+    We provide a  small number of 'project files'  for various IDEs to
+    automatically build  the library as  well.  Note that  these files
+    are not actively supported by FreeType developers,  they can break
+    or become obsolete.
+
+    To find them, have a  look at the content of the `builds/<system>`
+    directory, where <system> stands for your OS or environment.
+
+
+  5. From you own IDE, or own Makefiles
+
+    If  you  want  to  create   your  own  project  file,  follow  the
+    instructions   given  in  the   `INSTALL.ANY`  document   of  this
+    directory.
+
+
+III. Custom builds of the library
+=================================
+
+  Customizing the compilation  of FreeType is easy, and  allows you to
+  select only the components of  the font engine that you really need.
+  For more details read the file `CUSTOMIZE`.
+
+
+----------------------------------------------------------------------
+
+[1] make++, a make tool written in Perl, has sufficient support of GNU
+    make extensions to build FreeType.  See
+
+      https://makepp.sourceforge.net
+
+    for more information;  you need version 2.0 or newer, and you must
+    pass option `--norc-substitution`.
+
+----------------------------------------------------------------------
+
+Copyright (C) 2000-2023 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 INSTALL ---
diff --git a/contrib/libs/freetype/docs/INSTALL.ANY b/contrib/libs/freetype/docs/INSTALL.ANY
new file mode 100644
index 0000000000..bb77b1b9c2
--- /dev/null
+++ b/contrib/libs/freetype/docs/INSTALL.ANY
@@ -0,0 +1,157 @@
+Instructions on how to build FreeType with your own build tool
+==============================================================
+
+See  the  file `CUSTOMIZE'  to  learn  how  to customize  FreeType  to
+specific environments.
+
+
+I. Standard procedure
+---------------------
+
+  * If you use macro names  for FreeType header files (while mandatory
+    in earlier versions,  this is now optional  since FreeType version
+    2.6.1) it  is necessary to  disable pre-compiled headers.  This is
+    very important for Visual C++, because lines like
+
+      #include FT_FREETYPE_H
+
+    are not  correctly supported  by this compiler  while being  ISO C
+    compliant!
+
+  * You need to add the directory `include' to your  include path when
+    compiling the library.
+
+  * FreeType 2 is made of several  components; each of them is located
+    in    a   subdirectory    of    `freetype/src'.    For    example,
+    `freetype/src/truetype/' contains the TrueType font driver.
+
+  * DO NOT COMPILE ALL C FILES!  Rather, compile the following ones.
+
+    -- base components (required)
+
+      src/base/ftsystem.c
+      src/base/ftinit.c
+      src/base/ftdebug.c
+
+      src/base/ftbase.c
+
+      src/base/ftbbox.c       -- recommended, see <ftbbox.h>
+      src/base/ftglyph.c      -- recommended, see <ftglyph.h>
+
+      src/base/ftbdf.c        -- optional, see <ftbdf.h>
+      src/base/ftbitmap.c     -- optional, see <ftbitmap.h>
+      src/base/ftcid.c        -- optional, see <ftcid.h>
+      src/base/ftfstype.c     -- optional
+      src/base/ftgasp.c       -- optional, see <ftgasp.h>
+      src/base/ftgxval.c      -- optional, see <ftgxval.h>
+      src/base/ftmm.c         -- optional, see <ftmm.h>
+      src/base/ftotval.c      -- optional, see <ftotval.h>
+      src/base/ftpatent.c     -- optional
+      src/base/ftpfr.c        -- optional, see <ftpfr.h>
+      src/base/ftstroke.c     -- optional, see <ftstroke.h>
+      src/base/ftsynth.c      -- optional, see <ftsynth.h>
+      src/base/fttype1.c      -- optional, see <t1tables.h>
+      src/base/ftwinfnt.c     -- optional, see <ftwinfnt.h>
+
+      src/base/ftmac.c        -- only on the Macintosh
+
+    -- font drivers (optional; at least one is needed)
+
+      src/bdf/bdf.c           -- BDF font driver
+      src/cff/cff.c           -- CFF/OpenType font driver
+      src/cid/type1cid.c      -- Type 1 CID-keyed font driver
+      src/pcf/pcf.c           -- PCF font driver
+      src/pfr/pfr.c           -- PFR/TrueDoc font driver
+      src/sfnt/sfnt.c         -- SFNT files support
+                                 (TrueType & OpenType)
+      src/truetype/truetype.c -- TrueType font driver
+      src/type1/type1.c       -- Type 1 font driver
+      src/type42/type42.c     -- Type 42 font driver
+      src/winfonts/winfnt.c   -- Windows FONT / FNT font driver
+
+    -- rasterizers (optional; at least one is needed for vector
+       formats)
+
+      src/raster/raster.c     -- monochrome rasterizer
+      src/sdf/sdf.c           -- Signed Distance Field driver
+      src/smooth/smooth.c     -- anti-aliasing rasterizer
+
+    -- auxiliary modules (optional)
+
+      src/autofit/autofit.c   -- auto hinting module
+      src/cache/ftcache.c     -- cache sub-system (in beta)
+      src/gzip/ftgzip.c       -- support for compressed fonts (.gz)
+      src/lzw/ftlzw.c         -- support for compressed fonts (.Z)
+      src/bzip2/ftbzip2.c     -- support for compressed fonts (.bz2)
+      src/gxvalid/gxvalid.c   -- TrueTypeGX/AAT table validation
+      src/otvalid/otvalid.c   -- OpenType table validation
+      src/psaux/psaux.c       -- PostScript Type 1 parsing
+      src/pshinter/pshinter.c -- PS hinting module
+      src/psnames/psnames.c   -- PostScript glyph names support
+
+
+    Notes:
+
+      `ftcache.c'  needs `ftglyph.c'
+      `ftfstype.c' needs `fttype1.c'
+      `ftglyph.c'  needs `ftbitmap.c'
+      `ftstroke.c' needs `ftglyph.c'
+      `ftsynth.c'  needs `ftbitmap.c'
+
+      `cff.c'      needs `sfnt.c', `pshinter.c', and `psnames.c'
+      `truetype.c' needs `sfnt.c' and `psnames.c'
+      `type1.c'    needs `psaux.c' `pshinter.c', and `psnames.c'
+      `type1cid.c' needs `psaux.c', `pshinter.c', and `psnames.c'
+      `type42.c'   needs `truetype.c'
+
+      Please consult the central  `include/freetype/config/ftoption.h'
+      configuration file for details on additional libraries necessary
+      for some optional features.
+
+
+  Read the file `CUSTOMIZE' in case  you want to compile only a subset
+  of  the  drivers,  renderers,   and  optional  modules;  a  detailed
+  description of the various base  extension is given in the top-level
+  file `modules.cfg'.
+
+  You are done.  In case of problems, see the archives of the FreeType
+  development mailing list.
+
+
+II. Support for flat-directory compilation
+------------------------------------------
+
+  It is  possible to  put all  FreeType 2 source  files into  a single
+  directory, with the *exception* of the `include' hierarchy.
+
+  1. Copy all files in current directory
+
+      cp freetype/src/base/*.[hc] .
+      cp freetype/src/raster1/*.[hc] .
+      cp freetype/src/smooth/*.[hc] .
+      etc.
+
+  2. Compile sources
+
+      cc -c -Iinclude -DFT2_BUILD_LIBRARY ftsystem.c
+      cc -c -Iinclude -DFT2_BUILD_LIBRARY ftinit.c
+      cc -c -Iinclude -DFT2_BUILD_LIBRARY ftdebug.c
+      cc -c -Iinclude -DFT2_BUILD_LIBRARY ftbase.c
+      etc.
+
+    You don't  need to define  the FT_FLAT_COMPILATION macro  (as this
+    was required in previous releases of FreeType 2).
+
+----------------------------------------------------------------------
+
+Copyright (C) 2003-2023 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 INSTALL.ANY ---
diff --git a/contrib/libs/freetype/docs/INSTALL.CROSS b/contrib/libs/freetype/docs/INSTALL.CROSS
new file mode 100644
index 0000000000..21f4c31824
--- /dev/null
+++ b/contrib/libs/freetype/docs/INSTALL.CROSS
@@ -0,0 +1,177 @@
+This document contains instructions on how to cross-build the FreeType
+library on Unix systems, for example, building binaries for Linux/MIPS
+on  FreeBSD/i386.  Before  reading this  document, please  consult the
+file  `INSTALL.UNIX' for  required tools  and the  basic self-building
+procedure.
+
+
+  1. Required Tools
+  -----------------
+
+    For self-building the FreeType library  on a Unix system, GNU Make
+    3.81 or newer  is required.  `INSTALL.UNIX' contains  hints how to
+    check the installed `make'.
+
+    The GNU C  compiler to cross-build the target  system is required.
+    Currently, using a non-GNU cross  compiler is untested.  The cross
+    compiler is  expected to be  installed with a system  prefix.  For
+    example, if  your building system  is FreeBSD/i386 and  the target
+    system is Linux/MIPS, the cross  compiler should be installed with
+    the name `mips-ip22-linuxelf-gcc'.
+
+    A C  compiler for a self-build  is required also, to  build a tool
+    (`apinames') that is executed during the build procedure.  Non-GNU
+    self compilers are acceptable, but such a setup is untested.
+
+
+  2. Configuration
+  ----------------
+
+    2.1. Building and target system
+
+      To configure  a cross-build,  the options  `--host=<system>' and
+      `--build=<system>'  must be  passed to  the `configure'  script.
+      For example, if your build system is FreeBSD/i386 and the target
+      system is Linux/MIPS, say
+
+        ./configure \
+          --build=i386-unknown-freebsd \
+          --host=mips-ip22-linuxelf \
+          [other options]
+
+      It should  be noted that `--host=<system>'  specifies the system
+      where the built binaries will  be executed, not the system where
+      the build actually happens.   Older versions of GNU autoconf use
+      the option  pair `--host=' and `--target='.  This  is broken and
+      doesn't work.  Similarly, an explicit CC specification like
+
+        env CC=mips-ip22-linux-gcc ./configure                 # BAD
+
+      or
+
+        env CC=/usr/local/mips-ip22-linux/bin/gcc ./configure  # BAD
+
+      doesn't   work  either;  such   a  configuration   confuses  the
+      `configure' script while  trying to find the cross  and native C
+      compilers.
+
+
+    2.2. The prefix to install FreeType2
+
+      Setting `--prefix=<prefix>'  properly is important.   The prefix
+      to  install  FreeType2  is written  into  the  `freetype-config'
+      script and `freetype2.pc' configuration file.
+
+      If  the built  FreeType  2 library  is  used as  a  part of  the
+      cross-building system,  the prefix  is expected to  be different
+      from  the self-building  system.  For  example, a  configuration
+      with   `--prefix=/usr/local'   installs    binaries   into   the
+      system-wide `/usr/local' directory, which then can't be executed
+      due  to the  incorrect architecture.   This causes  confusion in
+      configuration of all applications  that use FreeType2.  Instead,
+      use a prefix  to install the cross-build into  a separate system
+      tree, for example, `--prefix=/usr/local/mips-ip22-linux/'.
+
+      On the other hand, if the built  FreeType 2 library is used as a
+      part of the target system,  the prefix to install should reflect
+      the file system structure of the target system.
+
+
+    2.3. Library dependencies
+
+      FreeType normally depends on external libraries like `libpng' or
+      `libharfbuzz'.   The  easiest case  is  to  deactivate all  such
+      dependencies  using the  `--without-XXX' configuration  options.
+      However, if you  want to use those libraries,  you should ensure
+      that  they  are available  both  on  the  target system  and  as
+      (cross-compiled) libraries on the build system.
+
+      FreeType uses  `pkg-config' to find  most of the  libraries; the
+      other libraries it links to  are expected in the standard system
+      directories.   Since the  default pkg-config's  meta-information
+      files (like `harfbuzz.pc') of the build platform don't work, use
+      one of the two possible solutions below.
+
+        o Use pkg-config's meta-information files that are adjusted to
+          cross-compile  and  cross-link  with the  target  platform's
+          libraries.  Make sure those files are found before the build
+          system's default files.  Example:
+
+            ./configure \
+              --build=i386-unknown-freebsd \
+              --host=mips-ip22-linuxelf \
+              PKG_CONFIG_LIBDIR="/usr/local/mips-ip22-linux/lib/pkgconfig" \
+              [other options]
+
+          See the manpage of `pkg-config' for more details.
+
+        o Set variables like LIBPNG_LIBS  as additional options to the
+          `configure' script, overriding the values `pkg-config' would
+          provide.  `configure --help' shows the available environment
+          variables.  Example:
+
+            ./configure \
+              --build=i386-unknown-freebsd \
+              --host=mips-ip22-linuxelf \
+              LIBPNG_CFLAGS="-I/usr/local/mips-ip22-linux/include" \
+              LIBPNG_LIBS="-L/usr/local/mips-ip22-linux/lib -lpng12" \
+              [other options]
+
+
+  3. Building command
+  -------------------
+
+    If  the  configuration  finishes successfully,  invoking  GNU make
+    builds FreeType2.  Just say
+
+      make
+
+    or
+
+      gmake
+
+    depending on the name the GNU make binary actually has.
+
+
+  4. Installation
+  ---------------
+
+    Saying
+
+      make install
+
+    as usual to install FreeType2 into the directory tree specified by
+    the argument of the `--prefix' option.
+
+    As noted in section 2.2,  FreeType2  is sometimes configured to be
+    installed  into the  system directory  of the  target  system, and
+    should  not be installed  in the  cross-building system.   In such
+    cases, the  make variable `DESTDIR'  is useful to change  the root
+    directory in the installation.  For example, after
+
+      make DESTDIR=/mnt/target_system_root/ install
+
+    the built FreeType2 library files are installed into the directory
+    `/mnt/target_system_root/<prefix_in_configure>/lib'.
+
+
+  5. TODO
+  -------
+
+    Cross building between Cygwin (or MSys) and Unix must be tested.
+
+
+----------------------------------------------------------------------
+
+Copyright (C) 2006-2023 by
+suzuki toshiya, 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 INSTALL.CROSS ---
diff --git a/contrib/libs/freetype/docs/INSTALL.GNU b/contrib/libs/freetype/docs/INSTALL.GNU
new file mode 100644
index 0000000000..7517d9c7c4
--- /dev/null
+++ b/contrib/libs/freetype/docs/INSTALL.GNU
@@ -0,0 +1,181 @@
+This document contains instructions how  to build the FreeType library
+on non-Unix systems with  the help of GNU Make.  Note  that if you are
+running  Cygwin  or  MinGW/MSYS  in Windows,  you  should  follow  the
+instructions in the file `INSTALL.UNIX' instead.
+
+
+  FreeType 2 includes a powerful and flexible build system that allows
+  you to  easily compile it on  a great variety of  platforms from the
+  command line.  To do so, just follow these simple instructions.
+
+  1. Install GNU Make
+  -------------------
+
+    The FreeType 2 build system relies on many features special to GNU
+    Make.
+
+    NEARLY ALL OTHER MAKE TOOLS  FAIL, INCLUDING `BSD MAKE', SO REALLY
+    INSTALL A RECENT VERSION OF GNU MAKE ON YOUR SYSTEM!
+
+    Note that  make++, a  make tool written  in Perl,  supports enough
+    features of GNU make to compile FreeType.  See
+
+      https://makepp.sourceforge.net
+
+    for more information;  you need version 2.0 or newer, and you must
+    pass option `--norc-substitution'.
+
+    Make sure that you are invoking GNU Make from the command line, by
+    typing something like:
+
+      make -v
+
+    to display its version number.
+
+    VERSION 3.81 OR NEWER IS NEEDED!
+
+
+  2. Invoke `make'
+  ----------------
+
+    Go to  the root  directory of FreeType  2, then simply  invoke GNU
+    Make from the command line.   This will launch the FreeType 2 host
+    platform  detection routines.   A summary  will be  displayed, for
+    example, on Win32.
+
+
+      ==============================================================
+      FreeType build system -- automatic system detection
+
+      The following settings are used:
+
+        platform                     windows
+        compiler                     gcc
+        configuration directory      .\builds\windows
+        configuration rules          .\builds\windows\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
+      or 'make refdoc' to build the API reference (the latter needs
+      Python >= 3.5).
+      =============================================================
+
+
+    If the detected settings correspond to your platform and compiler,
+    skip to step 5.  Note that if your platform is completely alien to
+    the build system, the detected platform will be `ansi'.
+
+
+  3. Configure the build system for a different compiler
+  ------------------------------------------------------
+
+    If the build system correctly detected your platform, but you want
+    to use a different compiler  than the one specified in the summary
+    (for most platforms, gcc is the default compiler), invoke GNU Make
+    with
+
+      make setup <compiler>
+
+    Examples:
+
+      to use Visual C++ on Win32, type:  `make setup visualc'
+      to use Borland C++ on Win32, type  `make setup bcc32'
+      to use Watcom C++ on Win32, type   `make setup watcom'
+      to use Intel C++ on Win32, type    `make setup intelc'
+      to use LCC-Win32 on Win32, type:   `make setup lcc'
+      to use Watcom C++ on OS/2, type    `make setup watcom'
+      to use VisualAge C++ on OS/2, type `make setup visualage'
+
+    The  <compiler> name to  use is  platform-dependent.  The  list of
+    available  compilers for  your  system is  available  in the  file
+    `builds/<system>/detect.mk'.
+
+    If you  are satisfied  by the new  configuration summary,  skip to
+    step 5.
+
+
+  3a. Use clang instead of gcc
+  ----------------------------
+
+    The `clang'  compiler can  use FreeType's setup  for `gcc';  it is
+    sufficient to set the `CC' variable, for example
+
+      make CC=clang
+
+
+  3b. Compiling with a C++ compiler
+  ---------------------------------
+
+    FreeType can be built with a C++ compiler, for example
+
+      make CC="g++"
+
+    If `clang++' should  be used it is necessary to  also override the
+    `ANSIFLAGS' variable:
+
+      make CC="clang++" ANSIFLAGS=""
+
+
+  4. Configure the build system for an unknown platform/compiler
+  --------------------------------------------------------------
+
+    The auto-detection/setup  phase of the build system  copies a file
+    to the current directory under the name `config.mk'.
+
+    For    example,    on    OS/2+gcc,    it   would    simply    copy
+    `builds/os2/os2-gcc.mk' to `./config.mk'.
+
+    If for  some reason your  platform isn't correctly  detected, copy
+    manually the configuration sub-makefile to `./config.mk' and go to
+    step 5.
+
+    Note  that  this file  is  a  sub-Makefile  used to  specify  Make
+    variables  for compiler  and linker  invocation during  the build.
+    You can  easily create your own  version from one  of the existing
+    configuration files,  then copy it to the  current directory under
+    the name `./config.mk'.
+
+
+  5. Build the library
+  --------------------
+
+    The auto-detection/setup  phase should have  copied a file  in the
+    current  directory,  called  `./config.mk'.   This  file  contains
+    definitions of various Make  variables used to invoke the compiler
+    and linker during the build.  [It has also generated a file called
+    `ftmodule.h'   in  the  objects   directory  (which   is  normally
+    `<toplevel>/objs/');  please read  the  file `docs/CUSTOMIZE'  for
+    customization of FreeType.]
+
+    To  launch  the build,  simply  invoke  GNU  Make again:  The  top
+    Makefile will detect the configuration file and run the build with
+    it.  If you have used variables in  step 3, you must use  the same
+    variables here, too.
+
+
+  Final note
+
+    The above instructions build a  _statically_ linked library of the
+    font engine in the `objs' directory.   On Windows, you can build a
+    DLL  either  with  MinGW  (within an  MSYS  shell,  following  the
+    instructions in `INSTALL.UNIX'), or you  use one of the Visual C++
+    project files; see  the  subdirectories  of `builds/windows'.  For
+    everything else,  you are on  your own,  and you might  follow the
+    instructions in `INSTALL.ANY' to create your own Makefiles.
+
+----------------------------------------------------------------------
+
+Copyright (C) 2003-2023 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 INSTALL.GNU ---
diff --git a/contrib/libs/freetype/docs/INSTALL.MAC b/contrib/libs/freetype/docs/INSTALL.MAC
new file mode 100644
index 0000000000..2587e24a65
--- /dev/null
+++ b/contrib/libs/freetype/docs/INSTALL.MAC
@@ -0,0 +1,32 @@
+Please follow the instructions in  INSTALL.UNIX to install FreeType on
+Mac OS X.
+
+Currently  FreeType2 functions  based on  some deprecated  Carbon APIs
+return  `FT_Err_Unimplemented_Feature' always,  even  if FreeType2  is
+configured and  built on  the system that  deprecated Carbon  APIs are
+available.   To  enable  deprecated  FreeType2  functions  as  far  as
+possible, replace `src/base/ftmac.c' by `builds/mac/ftmac.c'.
+
+Starting with  Mac OS X  10.5, gcc  defaults the deployment  target to
+10.5.  In previous  versions of Mac OS X, this  defaulted to 10.1.  If
+you want your built binaries to run only on 10.5, this change does not
+concern you.  If  you want them to  also run on older  versions of Mac
+OS  X,   then  you   must  either  set   the  MACOSX_DEPLOYMENT_TARGET
+environment  variable  or  pass `-mmacosx-version-min'  to  gcc.   You
+should specify the oldest  version of Mac OS you want  the code to run
+on.  For example, if you use Bourne shell:
+
+  export MACOSX_DEPLOYMENT_TARGET=10.2
+
+or, if you use C shell:
+
+  setenv MACOSX_DEPLOYMENT_TARGET 10.2
+
+Alternatively, you could pass `-mmacosx-version-min=10.2' to gcc.
+
+Here the number 10.2 is the lowest version that the built binaries can
+run on.  In the  above cases, the built binaries will run  on Mac OS X
+10.2 and later, but _not_ earlier.  If you want to run on earlier, you
+have to set lower version, e.g., 10.0.
+
+For classic Mac OS (Mac OS 7, 8, 9) please refer to builds/mac/README.
diff --git a/contrib/libs/freetype/docs/INSTALL.UNIX b/contrib/libs/freetype/docs/INSTALL.UNIX
new file mode 100644
index 0000000000..659f3a21f0
--- /dev/null
+++ b/contrib/libs/freetype/docs/INSTALL.UNIX
@@ -0,0 +1,139 @@
+This  document contains  instructions  on how  to  build the  FreeType
+library on Unix  systems.  This also works for  emulations like Cygwin
+or MSys on Win32:
+
+
+  1. Ensure that you are using GNU Make
+  -------------------------------------
+
+    The FreeType build system  _exclusively_ works with GNU Make.  You
+    will  not be  able to  compile the  library with  the instructions
+    below using any other alternative (including BSD Make).
+
+    Check that you have GNU make by running the command:
+
+       make -v
+
+    This should dump some text that begins with:
+
+       GNU Make  <version number>
+       Copyright (C) <year> Free Software Foundation Inc.
+
+    Note that version  3.81 or higher is *required* or the  build will
+    fail.
+
+    It is also fine to have GNU Make under another name (e.g. 'gmake')
+    if you use the MAKE variable as described below.
+
+    As  a  special exception,  'makepp'  can  also  be used  to  build
+    FreeType 2.  See the file docs/MAKEPP for details.
+
+    For builds  with `cmake' please check file `CMakeLists.txt';  this
+    is a contributed file not directly supported by the FreeType team.
+
+
+  2. Regenerate the configure script if needed
+  --------------------------------------------
+
+    This only applies if you  are building a git snapshot or checkout,
+    *not* if you grabbed the sources of an official release.
+
+    You  need  to invoke  the  `autogen.sh'  script  in the  top-level
+    directory  in order  to  create the  `configure'  script for  your
+    platform.  Normally, this simply means typing:
+
+      sh autogen.sh
+
+    In case of problems, you may  need to install or upgrade Automake,
+    Autoconf or Libtool.  See  `README.git' in the top-level directory
+    for more information.
+
+
+  3. Build and install the library
+  --------------------------------
+
+    Say
+
+      ./configure --help
+
+    to see  the list of  possible configuration options  and important
+    environment  variables.  The ./configure script  will detect  some
+    prerequisite  system  libraries  (libpng, brotli, etc.)  if  their
+    headers are available at the default locations.
+
+    The following  should work  on all Unix  systems where  the `make'
+    command invokes GNU Make:
+
+      ./configure [options]
+      make
+      make install           (as root)
+
+    The default installation path  is `/usr/local'.  It can be changed
+    with the `--prefix=<path>' option.  Example:
+
+      ./configure --prefix=/usr
+
+    When using  a different command  to invoke GNU Make,  use the MAKE
+    variable.  For example,  if `gmake' is the command  to use on your
+    system, do something like:
+
+       MAKE=gmake ./configure [options]
+       gmake
+       gmake install            (as root)
+
+    If  this still doesn't  work, there  must be  a problem  with your
+    system (e.g., you are using a very old version of GNU Make).
+
+    For library identification, FreeType's `configure' script uses the
+    `pkg-config' interface: Assuming it  needs library `foo', it calls
+    the  `pkg-config' program  to find  information on  library `foo',
+    which in turn  looks for a `foo.pc' file installed  at the system.
+    Some platforms,  however, don't come with  `pkg-support'; you then
+    have  to  use environment  variables  as  described by  `configure
+    --help'.  Example:
+
+      LIBPNG_CFLAGS="-I/path/to/libpng/include/directory" \
+      LIBPNG_LIBS="-L/path/to/libpng/lib/directory" \
+      configure ...
+
+    It  is possible  to  compile FreeType  in  a different  directory.
+    Assuming the FreeType source  files in directory `/src/freetype' a
+    compilation in directory `foo' works as follows:
+
+      cd foo
+      /src/freetype/configure [options]
+      make
+      make install
+
+
+  3.1 Interdependency with HarfBuzz
+  .................................
+
+    Note that there  is a chicken-and-egg problem  currently since the
+    HarfBuzz library  (used by the  auto-hinter to improve  support of
+    OpenType  fonts)  depends on  FreeType,  which  can be  solved  as
+    follows in case HarfBuzz is not yet installed on your system.
+
+    1. Call    FreeType's     `configure'    script     with    option
+       `--without-harfbuzz', then compile and install FreeType.
+
+    2. Compile and install HarfBuzz.
+
+    3. Call    FreeType's    `configure'   script    without    option
+       `--without-harfbuzz' (after  executing `make  distclean'), then
+       compile and install FreeType again.
+
+
+----------------------------------------------------------------------
+
+Copyright (C) 2003-2023 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 INSTALL.UNIX ---
diff --git a/contrib/libs/freetype/docs/INSTALL.VMS b/contrib/libs/freetype/docs/INSTALL.VMS
new file mode 100644
index 0000000000..4f8c3ac33d
--- /dev/null
+++ b/contrib/libs/freetype/docs/INSTALL.VMS
@@ -0,0 +1,69 @@
+How to build the FreeType library on VMS
+----------------------------------------
+
+It is actually  very straightforward to install  the FreeType library.
+Just execute `vms_make.com  from` the toplevel directory  to build the
+library.  This procedure currently accepts the following options:
+
+* `DEBUG`
+  Build the library with debug information and without optimization.
+
+* `lopts=<value>`
+  Options to pass to the link command, e.g., `lopts=/traceback`.
+
+* `ccopt=<value>`
+  Options to pass to the C compiler, e.g., `ccopt=/float=ieee`.
+
+In case you did download the demos, place them in a separate directory
+sharing the same top level as the directory of FreeType and follow the
+same  instructions as  above  for  the demos  from  there.  The  build
+process relies  on this  to figure  out the  location of  the FreeType
+include files.
+
+
+To rebuild  the  sources it is necessary to  have MMS/MMK installed on
+the system.
+
+The library is available in the directory
+
+  [.LIB]
+
+To compile applications using FreeType  you have to define the logical
+`FREETYPE` pointing to the directory
+
+  [.INCLUDE.FREETYPE]
+
+i.e., if the directory in which  this `INSTALL.VMS` file is located is
+`$disk:[freetype.docs]`, then define the logical with
+
+  define freetype $disk:[freetype.include.freetype]
+
+See  http://nchrem.tnw.tudelft.nl/openvms/software2.html#Freetype  for
+the packages FreeType depends on.
+
+The latest versions were tested using
+  - VSI C V7.4-002 and DECWindows V1.7-F on OpenVMS Alpha V8.4-2L1
+  - VSI C V7.4-001 and DECWindows V1.7-E on OpenVMS IA64 V8.4-2L3
+
+
+Any problems can be reported to
+
+  Jouk Jansen <joukj@hrem.nano.tudelft.nl> or
+
+Orginal version of the build procedures was created by
+
+  Martin P.J. Zinser <zinser@zinser.no-ip.info>
+
+------------------------------------------------------------------------
+
+Copyright (C) 2000-2023 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 INSTALL.VMS ---
diff --git a/contrib/libs/freetype/docs/README b/contrib/libs/freetype/docs/README
new file mode 100644
index 0000000000..c2b5af8650
--- /dev/null
+++ b/contrib/libs/freetype/docs/README
@@ -0,0 +1,33 @@
+After saying `make refdoc' or `make refdoc-venv' the `reference/' directory
+contains the FreeType API reference.  You need Python >= 3.5 and pip to make
+this target.
+
+There are two ways to generate the documentation:
+
+1. Using `make refdoc':
+
+    - Ensure `python' and `pip' are available.
+    - Install pip package `docwriter' with `pip install --user docwriter'.
+    - Make target with `make refdoc'.
+    - This target can be run offline once required packages are installed.
+
+2. Using `make refdoc-venv' (requires internet access):
+
+    - Ensure `python', `pip' and Python package `virtualenv' are available.
+    - Make target with `make refdoc-venv'.
+    - This may or may not require internet access every time depending on
+    pip and system caching.
+
+Some troubleshooting tips:
+
+* Regularly run `pip install --upgrade docwriter' to check for updates which
+may include bug fixes.
+
+* `Docwriter' does not support Python 2.  Ensure that Python >= 3.5 is
+installed and available as `python3'/`python'.
+
+* Ensure that `docwriter' is installed in the same Python target that
+`make refdoc' uses (python3/python).
+
+* If none of this works, send a mail to `freetype-devel@nongnu.org' or file
+an issue at `https://github.com/freetype/docwriter/issues'.
diff --git a/contrib/libs/freetype/docs/VERSIONS.TXT b/contrib/libs/freetype/docs/VERSIONS.TXT
new file mode 100644
index 0000000000..8b43c15837
--- /dev/null
+++ b/contrib/libs/freetype/docs/VERSIONS.TXT
@@ -0,0 +1,137 @@
+Due to  our use of  `libtool' to generate  and install the  FreeType 2
+libraries on Unix  systems, as well as other historical  events, it is
+generally very difficult  to know precisely which release  of the font
+engine is installed on a given system.
+
+This file tries to explain why and to document ways to properly detect
+FreeType on Unix.
+
+
+1. Version and Release numbers
+------------------------------
+
+For each new public release of FreeType 2, there are generally *three*
+distinct `version' numbers to consider:
+
+  * The official FreeType 2 release number, like 2.7.0 or 2.10.2.
+
+  * The  libtool (and  Unix)  specific version  number, like  23.2.17.
+    This is what
+
+      pkg-config freetype2 --modversion
+
+    or
+
+      freetype-config --version
+
+    returns.
+
+  * The platform-specific shared object  number, used for example when
+    the library is installed as `/usr/lib/libfreetype.so.6.17.2'.
+
+The platform-specific number is, unsurprisingly, platform-specific and
+varies with  the operating system  you are using (several  variants of
+Linux, FreeBSD, Solaris, etc.).  You  should thus _never_ use it, even
+for simple tests.
+
+The libtool-specific number  does not equal the release  number but is
+tied to it.
+
+The  release  number  is  available  at  *compile*  time  through  the
+following macros defined in `freetype.h':
+
+  - FREETYPE_MAJOR: major release number
+  - FREETYPE_MINOR: minor release number
+  - FREETYPE_PATCH: patch release number
+
+See below for a small autoconf fragment.
+
+The  release  number  is  also  available  at  *runtime*  through  the
+`FT_Library_Version' API.
+
+
+2. History
+----------
+
+The  following  table  gives,  for   all  releases  since  2.5.0,  the
+corresponding  libtool number,  as well  as the  shared object  number
+found on _most_ systems, but not all of them:
+
+
+    release     libtool     so
+  -------------------------------
+     2.13.2     26.1.20   6.20.1
+     2.13.1     26.0.20   6.20.0
+     2.13.0     25.0.19   6.19.0
+     2.12.1     24.3.18   6.18.3
+     2.12.0     24.2.18   6.18.2
+     2.11.1     24.1.18   6.18.1
+     2.11.0     24.0.18   6.18.0
+     2.10.4     23.4.17   6.17.4
+     2.10.3     23.3.17   6.17.3
+     2.10.2     23.2.17   6.17.2
+     2.10.1     23.1.17   6.17.1
+     2.10.0     23.0.17   6.17.0
+     2.9.1      22.1.16   6.16.1
+     2.9.0      22.0.16   6.16.0
+     2.8.1      21.0.15   6.15.0
+     2.8.0      20.0.14   6.14.0
+     2.7.1      19.0.13   6.13.0
+     2.7.0      18.6.12   6.12.6
+     2.6.5      18.5.12   6.12.5
+     2.6.4      18.4.12   6.12.4
+     2.6.3      18.3.12   6.12.3
+     2.6.2      18.2.12   6.12.2
+     2.6.1      18.1.12   6.12.1
+     2.6.0      18.0.12   6.12.0
+     2.5.5      17.4.11   6.11.4
+     2.5.4      17.3.11   6.11.3
+     2.5.3      17.2.11   6.11.2
+     2.5.2      17.1.11   6.11.1
+     2.5.1      17.0.11   6.11.0
+     2.5.0      16.2.10   6.10.2
+
+
+3. Autoconf Code Fragment
+-------------------------
+
+Lars  Clausen contributed  the  following autoconf  fragment to  check
+which version of FreeType is installed on a system (now updated to use
+`pkg-config'  instead of  `freetype-config').   This one  tests for  a
+version that is at least 2.10.2; you should change it to check against
+other release numbers.
+
+
+  AC_MSG_CHECKING([whether FreeType version is 2.10.2 or higher])
+  old_CPPFLAGS="$CPPFLAGS"
+  CPPFLAGS=`pkg-config freetype2 --cflags`
+  AC_TRY_CPP([
+
+#include <ft2build.h>
+#include <freetype/freetype.h>
+
+#if FREETYPE_MAJOR*10000 + FREETYPE_MINOR*100 + FREETYPE_PATCH < 21002
+#  error FreeType version too low.
+#endif
+
+  ],
+  [AC_MSG_RESULT(yes)
+   FREETYPE_LIBS=`pkg-config freetype2 --libs`
+   AC_SUBST(FREETYPE_LIBS)
+   AC_DEFINE(HAVE_FREETYPE,1,[Define if you have the FreeType2 library])
+   CPPFLAGS="$old_CPPFLAGS"],
+  [AC_MSG_ERROR([Need FreeType library version 2.10.2 or higher])])
+
+----------------------------------------------------------------------
+
+Copyright (C) 2002-2023 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 VERSIONS.TXT ---
diff --git a/contrib/libs/freetype/docs/formats.txt b/contrib/libs/freetype/docs/formats.txt
new file mode 100644
index 0000000000..882d62d231
--- /dev/null
+++ b/contrib/libs/freetype/docs/formats.txt
@@ -0,0 +1,223 @@
+This  file contains  a list  of various  font formats.   It gives  the
+reference document and whether it is supported in FreeType 2.
+
+Table fields
+------------
+
+  wrapper format
+    The format used to represent the font data.  In the table below it
+    is  used only  if the  font format  differs.  Possible  values are
+
+      SFNT  binary
+      PFB   binary
+      PS    a text header, followed by  binary or text data
+      LZW   compressed with  either `gzip' or `compress'
+      BZ2   compressed with `bzip2'.
+
+  font format
+    How the font is to be accessed, possibly after converting the file
+    type and wrapper  format into a generic form.   Bitmap formats are
+    `BDF',  `PCF', and  one form  of `WINFNT';  all others  are vector
+    formats.   `PS' indicates  third-order,  `TT' second-order  Bézier
+    curves.
+
+  font type
+    Sub-formats of the  font format.  `SBIT' and  `MACSBIT' are bitmap
+    formats,  `MM' and  `VAR' support  optical axes.   `CFF2' supports
+    optical axes also.
+
+  glyph access
+    If  not specified,  the glyph  access  is `standard'  to the  font
+    format.   Values are  `CID' for  CID-keyed fonts,  `SYNTHETIC' for
+    fonts that  are modified  versions of  other fonts  by means  of a
+    transformation matrix, and  `TYPE_0' for PS fonts which  are to be
+    accessed in a tree-like structure.
+
+  FreeType driver
+    The module in the FreeType library which handles the specific font
+    format.  A missing  entry means that FreeType  doesn't support the
+    font format (yet).
+
+
+Notes
+-----
+
+  The  SFNT  container  format also  provides  `collections'  (usually
+  having the file extension `.ttc'  or `.otc').  A collection contains
+  multiple font faces that share some tables to avoid redundancy, thus
+  reducing the file  size.  In FreeType, elements of  a collection can
+  be accessed with a proper face index.
+
+  Both  the GX  and the  OpenType 1.8  variation fonts  provide `named
+  instances'.  FreeType  maps them to  face indices (they can  also be
+  accessed with the standard MM interface).
+
+  Other  font  formats  (not  using the  SFNT  wrapper)  also  provide
+  multiple faces  within one  file; they are  marked with  an asterisk
+  (`*') in the table below.
+
+  FreeType can  be configured to  support Mac  files (on older  Mac OS
+  versions, a `file' is stored as a data and a resource fork, that is,
+  within two  separate data chunks).  If  a file can't be  opened as a
+  font, FreeType then checks whether it  is a resource fork, trying to
+  extract  the contained  font data  from  either a  `POST' or  `sfnt'
+  resource.
+
+
+Please  send additions  and/or  corrections to  wl@gnu.org  or to  the
+FreeType   developer's   list    at   freetype-devel@nongnu.org   (for
+subscribers only).   If you can  provide a  font example for  a format
+which isn't supported yet please send a mail too.
+
+
+  wrapper font    font    glyph      FreeType reference
+  format  format  type    access     driver   documents
+ -----------------------------------------------------------------------------
+
+  ---     BDF     ---     ---        bdf      5005.BDF_Spec.pdf, X11
+
+
+  SFNT    PS      TYPE_1  ---        type1    Type 1 GX Font Format [7]
+                                              (for the Mac; not supported)
+  SFNT    PS      TYPE_1  CID        cid      5180.sfnt.pdf (for the Mac) [3]
+  SFNT    PS      CFF     ---        cff      OT spec, 5176.CFF.pdf
+                                              (`OTTO' format)
+  SFNT    PS      CFF     CID        cff      OT spec, 5176.CFF.pdf
+  SFNT    PS      CFF     SYNTHETIC  ---      OT spec, 5176.CFF.pdf
+  SFNT    PS      CFF2    ---        cff      OT spec 1.8
+
+  SFNT    TT      SBIT    ---        sfnt     XFree86 (bitmaps only;
+                                              with `head' table)
+  SFNT    TT      MACSBIT ---        sfnt     OT spec (for the Mac;
+                                              bitmaps only; `bhed' table)
+  SFNT    TT      ---     ---        truetype OT spec (`normal' TT font)
+  SFNT    TT      VAR     ---        truetype GX spec (`?var' tables)
+  SFNT    TT      VAR     ---        truetype OT spec 1.8
+                                              (`?var' + `?VAR' tables)
+
+
+  WOFF    ---     ---     ---        cff,     Compressed SFNT, ver. 1.0 [6]
+                                     truetype
+  WOFF2   ---     ---     ---        cff,     Compressed SFNT, ver. 2.0 [6]
+                                     truetype
+
+
+  ---     PS      TYPE_1  ---        type1    T1_SPEC.pdf
+                                              (PFA, Type 1 font resource)
+  PFB     PS      TYPE_1  ---        type1    T1_SPEC.pdf,
+                                              5040.Download_Fonts.pdf
+                                              (`normal' Type 1 font)
+  ---     PS      TYPE_1  CID        cid      PLRM.pdf (CID Font Type 0;
+                                              Type 9 font)
+  ---     PS      MM      ---        type1    5015.Type1_Supp.pdf
+                                              (Multiple Masters)
+  ---     PS      CFF     ---        cff      5176.CFF.pdf (`pure' CFF)
+  ---     PS*     CFF     CID        cff      5176.CFF.pdf (`pure' CFF)
+  ---     PS      CFF     SYNTHETIC  ---      5176.CFF.pdf (`pure' CFF)
+  ---     PS      CFF/MM  ---        cff      old 5167.CFF.pdf (`pure' CFF)
+                                              [3]
+  ---     PS*     CFF/MM  CID        cff      old 5167.CFF.pdf (`pure' CFF)
+                                              [3]
+  ---     PS      CFF/MM  SYNTHETIC  ---      old 5167.CFF.pdf (`pure' CFF)
+                                              [3]
+  PS      PS      CFF     ---        ---      PLRM.pdf (Type 2) [1]
+  PS      PS*     CFF     CID        ---      PLRM.pdf (Type 2) [1]
+  PS      PS      CFF     SYNTHETIC  ---      PLRM.pdf (Type 2) [1]
+  PS      PS      CFF/MM  ---        ---      PLRM.pdf (Type 2) [1]
+  PS      PS*     CFF/MM  CID        ---      PLRM.pdf (Type 2) [1]
+  PS      PS      CFF/MM  SYNTHETIC  ---      PLRM.pdf (Type 2) [1]
+  ---     PS      ---     TYPE_0     ---      PLRM.pdf
+  ---     PS      TYPE_3  ---        ---      PLRM.pdf (never supported)
+  ---     PS      TYPE_3  CID        ---      PLRM.pdf (CID Font Type 1;
+                                              Type 10 font; never supported)
+  PS      PS      TYPE_14 ---        ---      PLRM.pdf (Chameleon font;
+                                              Type 14 font; never supported?)
+  ---     PS      TYPE_32 CID        ---      PLRM.pdf (CID Font Type 4;
+                                              Type 32 font; never supported?)
+  PS      TT      ---     ---        type42   5012.Type42_Spec.pdf
+                                              (Type 42 font)
+  PS      TT      ---     CID        ---      PLRM.pdf (CID Font Type 2;
+                                              Type 11 font)
+
+
+  ?       ?       CEF     ?          cff      ?
+
+
+  ---     PCF     ---     ---        pcf      X11 [4]
+  LZW     PCF     ---     ---        pcf      X11 [4]
+  BZ2     PCF     ---     ---        pcf      X11 [4]
+
+
+  ---     PFR*    PFR0    ---        pfr      [2]
+  ---     PFR     PFR1    ---        ---      (undocumented, proprietary;
+                                              probably never supported)
+
+
+  ---     WINFNT* ---     ---        winfonts Windows developer's notes [5]
+  ---     WINFNT  VECTOR  ---        ---      Windows developer's notes [5]
+
+
+[1] Support should  be rather simple since this is  identical to `CFF'
+    but in a PS wrapper.
+
+[2] The  official  PFR  specification  is  no  longer  available,  but
+    archive.org has archived it:
+
+      https://web.archive.org/web/20091014062300/http://www.bitstream.com/font_rendering/products/truedoc/pfrspec.html
+      https://web.archive.org/web/20081115152605/http://www.bitstream.com/font_rendering/pdfs/pfrspec1.3.pdf
+
+    The syntax  of the  auxiliary data  is not  defined there,  but is
+    partially defined in MHP 1.0.3 (also called ETSI TS 101812 V1.3.1)
+    section 7.4.
+
+      https://www.etsi.org/
+      https://webapp.etsi.org/workprogram/Report_WorkItem.asp?WKI_ID=18799
+
+[3] Support  is rudimentary  currently; some  tables or  data are  not
+    loaded yet.
+
+[4] See
+
+      THE X WINDOW SYSTEM SERVER: X VERSION 11, RELEASE 5
+      Elias Israel, Erik Fortune, Digital Press, 1992
+      ISBN 1-55558-096-3
+
+    for a specification given in Appendix D on pgs. 436-450.  However,
+    this information might be out  of date; unfortunately, there is no
+    PCF specification available online, and this book is out of print.
+    George Williams deduced  the font format from the  X11 sources and
+    documented it for his FontForge font editor:
+
+      https://fontforge.github.io/pcf-format.html
+
+[5] This is from MS Windows 3;  see Microsoft's Knowledge Base article
+    at
+
+      https://support.microsoft.com/kb/65123
+
+[6] Supported  font  formats  are   TrueType  and  OpenType  fonts  as
+    defined in the OpenType specification 1.6 and newer.
+
+[7] `The Type 1 GX Font Format' (dated 1995-09-27)  was distributed in
+    Apple Developer CD-ROM in those days.  The content of `TYP1' table
+    is a PostScript Type 1 font without the eexec encryption.  Current
+    versions of FreeType don't not support this format,  but FontForge
+    can load it.
+
+------------------------------------------------------------------------
+
+Copyright (C) 2004-2023 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 formats.txt ---
+
+Local Variables:
+coding: utf-8
+End:
diff --git a/contrib/libs/freetype/docs/raster.txt b/contrib/libs/freetype/docs/raster.txt
new file mode 100644
index 0000000000..1642a81d9d
--- /dev/null
+++ b/contrib/libs/freetype/docs/raster.txt
@@ -0,0 +1,635 @@
+
+                   How FreeType's rasterizer work
+
+                          by David Turner
+
+                        Revised 2007-Feb-01
+
+
+This file  is an  attempt to explain  the internals of  the FreeType
+rasterizer.  The  rasterizer is of  quite general purpose  and could
+easily be integrated into other programs.
+
+
+  I. Introduction
+
+ II. Rendering Technology
+     1. Requirements
+     2. Profiles and Spans
+        a. Sweeping the Shape
+        b. Decomposing Outlines into Profiles
+        c. The Render Pool
+        d. Computing Profiles Extents
+        e. Computing Profiles Coordinates
+        f. Sweeping and Sorting the Spans
+
+
+I. Introduction
+===============
+
+  A  rasterizer is  a library  in charge  of converting  a vectorial
+  representation of a shape  into a bitmap.  The FreeType rasterizer
+  has  been  originally developed  to  render  the  glyphs found  in
+  TrueType  files, made  up  of segments  and second-order  Béziers.
+  Meanwhile it has been extended to render third-order Bézier curves
+  also.   This  document  is   an  explanation  of  its  design  and
+  implementation.
+
+  While  these explanations start  from the  basics, a  knowledge of
+  common rasterization techniques is assumed.
+
+
+II. Rendering Technology
+========================
+
+1. Requirements
+---------------
+
+  We  assume that  all scaling,  rotating, hinting,  etc.,  has been
+  already done.  The glyph is thus  described by a list of points in
+  the device space.
+
+  - All point coordinates  are in the 26.6 fixed  float format.  The
+    used orientation is:
+
+
+       ^ y
+       |         reference orientation
+       |
+       *----> x
+      0
+
+
+    `26.6' means  that 26 bits  are used for  the integer part  of a
+    value   and  6   bits  are   used  for   the   fractional  part.
+    Consequently, the `distance'  between two neighbouring pixels is
+    64 `units' (1 unit = 1/64 of a pixel).
+
+    Note  that, for  the rasterizer,  pixel centers  are  located at
+    integer   coordinates.   The   TrueType   bytecode  interpreter,
+    however, assumes that  the lower left edge of  a pixel (which is
+    taken  to be  a square  with  a length  of 1  unit) has  integer
+    coordinates.
+
+
+        ^ y                                        ^ y
+        |                                          |
+        |            (1,1)                         |      (0.5,0.5)
+        +-----------+                        +-----+-----+
+        |           |                        |     |     |
+        |           |                        |     |     |
+        |           |                        |     o-----+-----> x
+        |           |                        |   (0,0)   |
+        |           |                        |           |
+        o-----------+-----> x                +-----------+
+      (0,0)                             (-0.5,-0.5)
+
+   TrueType bytecode interpreter          FreeType rasterizer
+
+
+    A pixel line in the target bitmap is called a `scanline'.
+
+  - A  glyph  is  usually  made  of several  contours,  also  called
+    `outlines'.  A contour is simply a closed curve that delimits an
+    outer or inner region of the glyph.  It is described by a series
+    of successive points of the points table.
+
+    Each point  of the glyph  has an associated flag  that indicates
+    whether  it is  `on' or  `off' the  curve.  Two  successive `on'
+    points indicate a line segment joining the two points.
+
+    One `off' point amidst two `on' points indicates a second-degree
+    (conic)  Bézier parametric  arc, defined  by these  three points
+    (the `off' point being the  control point, and the `on' ones the
+    start and end points).  Similarly, a third-degree (cubic) Bézier
+    curve  is described  by four  points (two  `off'  control points
+    between two `on' points).
+
+    Finally,  for  second-order curves  only,  two successive  `off'
+    points  forces the  rasterizer to  create, during  rendering, an
+    `on'  point amidst them,  at their  exact middle.   This greatly
+    facilitates the  definition of  successive Bézier arcs.
+
+  The parametric form of a second-order Bézier curve is:
+
+      P(t) = (1-t)^2*P1 + 2*t*(1-t)*P2 + t^2*P3
+
+      (P1 and P3 are the end points, P2 the control point.)
+
+  The parametric form of a third-order Bézier curve is:
+
+      P(t) = (1-t)^3*P1 + 3*t*(1-t)^2*P2 + 3*t^2*(1-t)*P3 + t^3*P4
+
+      (P1 and P4 are the end points, P2 and P3 the control points.)
+
+  For both formulae, t is a real number in the range [0..1].
+
+  Note  that the rasterizer  does not  use these  formulae directly.
+  They exhibit,  however, one very  useful property of  Bézier arcs:
+  Each  point of  the curve  is a  weighted average  of  the control
+  points.
+
+  As all weights  are positive and always sum up  to 1, whatever the
+  value  of t,  each arc  point lies  within the  triangle (polygon)
+  defined by the arc's three (four) control points.
+
+  In  the following,  only second-order  curves are  discussed since
+  rasterization of third-order curves is completely identical.
+
+  Here some samples for second-order curves.
+
+
+                                        *            # on curve
+                                                     * off curve
+                                     __---__
+        #-__                      _--       -_
+            --__                _-            -
+                --__           #               \
+                    --__                        #
+                        -#
+                                 Two `on' points
+         Two `on' points       and one `off' point
+                                  between them
+
+                      *
+        #            __      Two `on' points with two `off'
+         \          -  -     points between them. The point
+          \        /    \    marked `0' is the middle of the
+           -      0      \   `off' points, and is a `virtual
+            -_  _-       #   on' point where the curve passes.
+              --             It does not appear in the point
+              *              list.
+
+
+2. Profiles and Spans
+---------------------
+
+  The following is a basic explanation of the _kind_ of computations
+  made  by  the   rasterizer  to  build  a  bitmap   from  a  vector
+  representation.  Note  that the actual  implementation is slightly
+  different, due to performance tuning and other factors.
+
+  However, the following ideas remain  in the same category, and are
+  more convenient to understand.
+
+
+  a. Sweeping the Shape
+
+    The best way to fill a shape is to decompose it into a number of
+    simple  horizontal segments,  then turn  them on  in  the target
+    bitmap.  These segments are called `spans'.
+
+                __---__
+             _--       -_
+           _-            -
+          -               \
+         /                 \
+        /                   \
+       |                     \
+
+                __---__         Example: filling a shape
+             _----------_                with spans.
+           _--------------
+          ----------------\
+         /-----------------\    This is typically done from the top
+        /                   \   to the bottom of the shape, in a
+       |           |         \  movement called a `sweep'.
+                   V
+
+                __---__
+             _----------_
+           _--------------
+          ----------------\
+         /-----------------\
+        /-------------------\
+       |---------------------\
+
+
+    In  order  to draw  a  span,  the  rasterizer must  compute  its
+    coordinates, which  are simply the x coordinates  of the shape's
+    contours, taken on the y scanlines.
+
+
+                   /---/    |---|   Note that there are usually
+                  /---/     |---|   several spans per scanline.
+        |        /---/      |---|
+        |       /---/_______|---|   When rendering this shape to the
+        V      /----------------|   current scanline y, we must
+              /-----------------|   compute the x values of the
+           a /----|         |---|   points a, b, c, and d.
+      - - - *     * - - - - *   * - - y -
+           /     / b       c|   |d
+
+
+                   /---/    |---|
+                  /---/     |---|  And then turn on the spans a-b
+                 /---/      |---|  and c-d.
+                /---/_______|---|
+               /----------------|
+              /-----------------|
+           a /----|         |---|
+      - - - ####### - - - - ##### - - y -
+           /     / b       c|   |d
+
+
+  b. Decomposing Outlines into Profiles
+
+    For  each  scanline during  the  sweep,  we  need the  following
+    information:
+
+    o The  number of  spans on  the current  scanline, given  by the
+      number of  shape points  intersecting the scanline  (these are
+      the points a, b, c, and d in the above example).
+
+    o The x coordinates of these points.
+
+    x coordinates are  computed before the sweep, in  a phase called
+    `decomposition' which converts the glyph into *profiles*.
+
+    Put it simply, a `profile'  is a contour's portion that can only
+    be either ascending or descending,  i.e., it is monotonic in the
+    vertical direction (we also say  y-monotonic).  There is no such
+    thing as a horizontal profile, as we shall see.
+
+    Here are a few examples:
+
+
+      this square
+                                          1         2
+         ---->----     is made of two
+        |         |                       |         |
+        |         |       profiles        |         |
+        ^         v                       ^    +    v
+        |         |                       |         |
+        |         |                       |         |
+         ----<----
+
+                                         up        down
+
+
+      this triangle
+
+             P2                             1          2
+
+             |\        is made of two       |         \
+          ^  | \  \                         |          \
+          | |   \  \      profiles         |            \      |
+         |  |    \  v                  ^   |             \     |
+           |      \                    |  |         +     \    v
+           |       \                   |  |                \
+        P1 ---___   \                     ---___            \
+                 ---_\                          ---_         \
+             <--__     P3                   up           down
+
+
+
+      A more general contour can be made of more than two profiles:
+
+              __     ^
+             /  |   /  ___          /    |
+            /   |     /   |        /     |       /     |
+           |    |    /   /    =>  |      v      /     /
+           |    |   |   |         |      |     ^     |
+        ^  |    |___|   |  |      ^   +  |  +  |  +  v
+        |  |           |   v      |                 |
+           |           |          |           up    |
+           |___________|          |    down         |
+
+                <--               up              down
+
+
+    Successive  profiles are  always joined  by  horizontal segments
+    that are not part of the profiles themselves.
+
+    For  the  rasterizer,  a  profile  is  simply  an  *array*  that
+    associates  one  horizontal *pixel*  coordinate  to each  bitmap
+    *scanline*  crossed  by  the  contour's section  containing  the
+    profile.  Note that profiles are *oriented* up or down along the
+    glyph's original flow orientation.
+
+    In other graphics libraries, profiles are also called `edges' or
+    `edgelists'.
+
+
+  c. The Render Pool
+
+    FreeType  has been designed  to be  able to  run well  on _very_
+    light systems, including embedded systems with very few memory.
+
+    A render pool  will be allocated once; the  rasterizer uses this
+    pool for all  its needs by managing this  memory directly in it.
+    The  algorithms that are  used for  profile computation  make it
+    possible to use  the pool as a simple  growing heap.  This means
+    that this  memory management is  actually quite easy  and faster
+    than any kind of malloc()/free() combination.
+
+    Moreover,  we'll see  later that  the rasterizer  is  able, when
+    dealing with profiles too large  and numerous to lie all at once
+    in  the render  pool, to  immediately decompose  recursively the
+    rendering process  into independent sub-tasks,  each taking less
+    memory to be performed (see `sub-banding' below).
+
+    The  render pool doesn't  need to  be large.   A 4KByte  pool is
+    enough for nearly all renditions, though nearly 100% slower than
+    a more comfortable 16KByte or 32KByte pool (that was tested with
+    complex glyphs at sizes over 500 pixels).
+
+
+  d. Computing Profiles Extents
+
+    Remember that a profile is an array, associating a _scanline_ to
+    the x pixel coordinate of its intersection with a contour.
+
+    Though it's not exactly how the FreeType rasterizer works, it is
+    convenient  to think  that  we need  a  profile's height  before
+    allocating it in the pool and computing its coordinates.
+
+    The profile's height  is the number of scanlines  crossed by the
+    y-monotonic section of a contour.  We thus need to compute these
+    sections from  the vectorial description.  In order  to do that,
+    we are  obliged to compute all  (local and global)  y extrema of
+    the glyph (minima and maxima).
+
+
+           P2             For instance, this triangle has only
+                          two y-extrema, which are simply
+           |\
+           | \               P2.y  as a vertical maximum
+          |   \              P3.y  as a vertical minimum
+          |    \
+         |      \            P1.y is not a vertical extremum (though
+         |       \           it is a horizontal minimum, which we
+      P1 ---___   \          don't need).
+               ---_\
+                     P3
+
+
+    Note  that the  extrema are  expressed  in pixel  units, not  in
+    scanlines.   The triangle's  height  is certainly  (P3.y-P2.y+1)
+    pixel  units,   but  its  profiles'  heights   are  computed  in
+    scanlines.  The exact conversion is simple:
+
+      - min scanline = FLOOR  ( min y )
+      - max scanline = CEILING( max y )
+
+    A problem  arises with Bézier  Arcs.  While a segment  is always
+    necessarily y-monotonic (i.e.,  flat, ascending, or descending),
+    which makes extrema computations easy,  the ascent of an arc can
+    vary between its control points.
+
+
+                          P2
+                         *
+                                       # on curve
+                                       * off curve
+                   __-x--_
+                _--       -_
+          P1  _-            -          A non y-monotonic Bézier arc.
+             #               \
+                              -        The arc goes from P1 to P3.
+                               \
+                                \  P3
+                                 #
+
+
+    We first  need to be  able to easily detect  non-monotonic arcs,
+    according to  their control points.  I will  state here, without
+    proof, that the monotony condition can be expressed as:
+
+      P1.y <= P2.y <= P3.y   for an ever-ascending arc
+
+      P1.y >= P2.y >= P3.y   for an ever-descending arc
+
+    with the special case of
+
+      P1.y = P2.y = P3.y     where the arc is said to be `flat'.
+
+    As  you can  see, these  conditions can  be very  easily tested.
+    They are, however, extremely important, as any arc that does not
+    satisfy them necessarily contains an extremum.
+
+    Note  also that  a monotonic  arc can  contain an  extremum too,
+    which is then one of its `on' points:
+
+
+        P1           P2
+          #---__   *         P1P2P3 is ever-descending, but P1
+                -_           is an y-extremum.
+                  -
+           ---_    \
+               ->   \
+                     \  P3
+                      #
+
+
+    Let's go back to our previous example:
+
+
+                          P2
+                         *
+                                       # on curve
+                                       * off curve
+                   __-x--_
+                _--       -_
+          P1  _-            -          A non-y-monotonic Bézier arc.
+             #               \
+                              -        Here we have
+                               \              P2.y >= P1.y &&
+                                \  P3         P2.y >= P3.y      (!)
+                                 #
+
+
+    We need to  compute the vertical maximum of this  arc to be able
+    to compute a profile's height (the point marked by an `x').  The
+    arc's equation indicates that  a direct computation is possible,
+    but  we rely  on a  different technique,  which use  will become
+    apparent soon.
+
+    Bézier  arcs have  the  special property  of  being very  easily
+    decomposed into two sub-arcs,  which are themselves Bézier arcs.
+    Moreover, it is easy to prove that there is at most one vertical
+    extremum on  each Bézier arc (for  second-degree curves; similar
+    conditions can be found for third-order arcs).
+
+    For instance,  the following arc  P1P2P3 can be  decomposed into
+    two sub-arcs Q1Q2Q3 and R1R2R3:
+
+
+                    P2
+                   *
+                                    # on  curve
+                                    * off curve
+
+
+                                    original Bézier arc P1P2P3.
+                __---__
+             _--       --_
+           _-             -_
+          -                 -
+         /                   \
+        /                     \
+       #                       #
+     P1                         P3
+
+
+
+                    P2
+                   *
+
+
+
+                   Q3                 Decomposed into two subarcs
+          Q2                R2        Q1Q2Q3 and R1R2R3
+            *   __-#-__   *
+             _--       --_
+           _-       R1    -_          Q1 = P1         R3 = P3
+          -                 -         Q2 = (P1+P2)/2  R2 = (P2+P3)/2
+         /                   \
+        /                     \            Q3 = R1 = (Q2+R2)/2
+       #                       #
+     Q1                         R3    Note that Q2, R2, and Q3=R1
+                                      are on a single line which is
+                                      tangent to the curve.
+
+
+    We have then decomposed  a non-y-monotonic Bézier curve into two
+    smaller sub-arcs.  Note that in the above drawing, both sub-arcs
+    are monotonic, and that the extremum is then Q3=R1.  However, in
+    a  more general  case,  only  one sub-arc  is  guaranteed to  be
+    monotonic.  Getting back to our former example:
+
+
+                    Q2
+                   *
+
+                   __-x--_ R1
+                _--       #_
+          Q1  _-        Q3  -   R2
+             #               \ *
+                              -
+                               \
+                                \  R3
+                                 #
+
+
+    Here, we see that,  though Q1Q2Q3 is still non-monotonic, R1R2R3
+    is ever  descending: We  thus know that  it doesn't  contain the
+    extremum.  We can then re-subdivide Q1Q2Q3 into two sub-arcs and
+    go  on recursively,  stopping  when we  encounter two  monotonic
+    subarcs, or when the subarcs become simply too small.
+
+    We  will finally  find  the vertical  extremum.   Note that  the
+    iterative process of finding an extremum is called `flattening'.
+
+
+  e. Computing Profiles Coordinates
+
+    Once we have the height of each profile, we are able to allocate
+    it in the render pool.   The next task is to compute coordinates
+    for each scanline.
+
+    In  the case  of segments,  the computation  is straightforward,
+    using  the  Euclidean   algorithm  (also  known  as  Bresenham).
+    However, for Bézier arcs, the job is a little more complicated.
+
+    We assume  that all Béziers that  are part of a  profile are the
+    result of  flattening the curve,  which means that they  are all
+    y-monotonic (ascending  or descending, and never  flat).  We now
+    have  to compute the  intersections of  arcs with  the profile's
+    scanlines.  One  way is  to use a  similar scheme  to flattening
+    called `stepping'.
+
+
+                                 Consider this arc, going from P1 to
+      ---------------------      P3.  Suppose that we need to
+                                 compute its intersections with the
+                                 drawn scanlines.  As already
+      ---------------------      mentioned this can be done
+                                 directly, but the involved
+          * P2         _---# P3  algorithm is far too slow.
+      ------------- _--  --
+                  _-
+                _/               Instead, it is still possible to
+      ---------/-----------      use the decomposition property in
+              /                  the same recursive way, i.e.,
+             |                   subdivide the arc into subarcs
+      ------|--------------      until these get too small to cross
+            |                    more than one scanline!
+           |
+      -----|---------------      This is very easily done using a
+          |                      rasterizer-managed stack of
+          |                      subarcs.
+          # P1
+
+
+  f. Sweeping and Sorting the Spans
+
+    Once all our profiles have  been computed, we begin the sweep to
+    build (and fill) the spans.
+
+    As both the  TrueType and Type 1 specifications  use the winding
+    fill  rule (but  with opposite  directions), we  place,  on each
+    scanline, the present profiles in two separate lists.
+
+    One  list,  called  the  `left'  one,  only  contains  ascending
+    profiles, while  the other `right' list  contains the descending
+    profiles.
+
+    As  each glyph  is made  of  closed curves,  a simple  geometric
+    property ensures that  the two lists contain the  same number of
+    elements.
+
+    Creating spans is thus straightforward:
+
+    1. We sort each list in increasing horizontal order.
+
+    2. We pair  each value of  the left list with  its corresponding
+       value in the right list.
+
+
+                   /     /  |   |          For example, we have here
+                  /     /   |   |          four profiles.  Two of
+                >/     /    |   |  |       them are ascending (1 &
+              1//     /   ^ |   |  | 2     3), while the two others
+              //     //  3| |   |  v       are descending (2 & 4).
+              /     //4   | |   |          On the given scanline,
+           a /     /<       |   |          the left list is (1,3),
+      - - - *-----* - - - - *---* - - y -  and the right one is
+           /     / b       c|   |d         (4,2) (sorted).
+
+                                   There are then two spans, joining
+                                   1 to 4 (i.e. a-b) and 3 to 2
+                                   (i.e. c-d)!
+
+
+    Sorting doesn't necessarily  take much time, as in  99 cases out
+    of 100, the lists' order is  kept from one scanline to the next.
+    We can  thus implement it  with two simple  singly-linked lists,
+    sorted by a classic bubble-sort, which takes a minimum amount of
+    time when the lists are already sorted.
+
+    A  previous  version  of  the  rasterizer  used  more  elaborate
+    structures, like arrays to  perform `faster' sorting.  It turned
+    out that  this old scheme is  not faster than  the one described
+    above.
+
+    Once the spans  have been `created', we can  simply draw them in
+    the target bitmap.
+
+------------------------------------------------------------------------
+
+Copyright (C) 2003-2023 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 raster.txt ---
+
+Local Variables:
+coding: utf-8
+End: