* Version 2.5.5 released.
=========================

Tag sources with `VER-2-5-5'.

* docs/VERSION.DLL: Update documentation and bump version number to
2.5.5.

* README, Jamfile (RefDoc), builds/windows/vc2005/freetype.vcproj,
builds/windows/vc2005/index.html,
builds/windows/vc2008/freetype.vcproj,
builds/windows/vc2008/index.html,
builds/windows/vc2010/freetype.vcxproj,
builds/windows/vc2010/index.html,
builds/windows/visualc/freetype.dsp,
builds/windows/visualc/freetype.vcproj,
builds/windows/visualc/index.html,
builds/windows/visualce/freetype.dsp,
builds/windows/visualce/freetype.vcproj,
builds/windows/visualce/index.html,
builds/wince/vc2005-ce/freetype.vcproj,
builds/wince/vc2005-ce/index.html,
builds/wince/vc2008-ce/freetype.vcproj,
builds/wince/vc2008-ce/index.html: s/2.5.4/2.5.5/, s/254/255/.

* include/freetype/freetype.h (FREETYPE_PATCH): Set to 5.

* builds/unix/configure.raw (version_info): Set to 17:4:11.
* CMakeLists.txt (VERSION_PATCH): Set to 5.
* docs/CHANGES: Updated.

* builds/toplevel.mk (dist): Fix typos.
[type42] Remove unused member extension_component
[threadsafety] Allocate AF_Loader on the stack instead of AF_Module

Stop sharing a global AF_Loader.  Allocate one on the stack during
glyph load.

Right now results in about 25% slowdown.  However, I don't fully
understand why that should be as all the init/done really does is
clearing memory.  Will investigate more.

With this patch loading glyphs from different faces from different
threads doesn't immediately crash in the autohinting loader code.

Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1164941
[threadsafety] Allocate TT_ExecContext in TT_Size instead of TT_Driver

Previously the code had stipulation for using a per-TT_Size exec
context if size->debug was true.  But there was no way that size->debug
could *ever* be true.  As such, the code was always using the singleton
TT_ExecContext that was stored in TT_Driver.  This was, clearly, not
threadsafe.

Remove size->debug.

Remove TT_Driver-global TT_ExecContext.

Lazy-create a TT_ExecContext for the TT_Size when needed.

With this patch loading glyphs from different faces from different
threads doesn't crash in the bytecode loader code.
[threadsafety] Allocate render pool for smooth rasterizer on the stack

Instead of using the render_pool member of FT_Library that is provided
down to the raterizer, completely ignore that and allocate needed
objects on the stack instead.

With this patch rasterizing glyphs from different faces from different
threads doesn't crash in the smooth rasterizer.

Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=678397
https://bugzilla.redhat.com/show_bug.cgi?id=1004315
https://bugs.freedesktop.org/show_bug.cgi?id=69034
https://bugzilla.redhat.com/show_bug.cgi?id=1165471
[raster] Remove 5-level gray AA mode from monochrome rasterizer

It was off by default and couldn't be turned on at runtime.
And the smooth rasterizer has had superceded it over ten years ago.
No point in keeping.  Comments suggested that it was there for
compatibility with FreeType 1.

550 lines down.
[threadsafety] Allocate render pool for mono rasterizer on the stack

Instead of using the render_pool member of FT_Library that is provided
down to the raterizer, completely ignore that and allocate needed
objects on the stack instead.

With this patch rasterizing glyphs from different faces from different
threads doesn't crash in the monochrome rasterizer.
[threadsafety] Do not reorder library->renderers upon use

Instead of keeping library->renderers in a MRU order, just leave
it as is.  The MRU machinery was an overengineering premature
optimization to begin with.  And wasn't thread-safe.

With this patch rasterizing glyphs from different faces from different
threads doesn't fail choosing rasterizer (FT_Err_Cannot_Render_Glyph).

Easiest to see that crash was to add a printf or otherwise let thread
yield in FT_Throw with debugging enabled.
[library] Don't allocate library->raster_pool anymore

It's unused after the following commits:

  commit a6ff9bee1dae88971ef35e1a2ca39b2b76fe26b5
  [threadsafety] Allocate render pool for mono rasterizer on the stack

  commit 0610348976f376a931cea534ce5936136379b8c0
  [raster] Remove 5-level gray AA mode from monochrome rasterizer

The value of FT_RENDER_POOL_SIZE still serves the purpose it used to
serve, which is, to adjust the pool size.  But the pool is now
allocated on the stack on demand.