library when dealing with certain weird fonts (like "Stalingrad",
in "sadn.pfb". This font has no full font name entry.. )
* src/base/ftoutln.c, include/freetype/ftoutln.h: added the
FT_Outline_Check API to check the consistency of outline data
* src/base/ftobjs.c (FT_Load_Glyph): added a call to the new
FT_Outline_Check to ensure that loaded glyphs are valid. This
allows certain fonts like "tt1095m_.ttf" to be loaded even though
it appears they contain really funky glyphs..
there still is a bug there though.. !!
* src/pshinter/pshrec.c: now ignores invalid "hintmask" and "cntrmask"
operators (instead of returning an error). Glyph 2028 of the CFF font
"MSung-Light-Acro" couldn't be rendered otherwise (it seems its
charstring is buggy, though this requires more analysis)..
src/pshinter/ahalgo2.c, src/pshinter/pshglob.h: fixed a bug where
the X and Y axis where inversed in the postscript hinter. this
caused problem when displaying on non-square surfaces..
constant with a fixed-float equivalent. For some reason, some compilers
aren't capable of directly computing a floating pointer constant casted
to FT_Fixed, and will link a math library instead !!
* src/cff/cffload.h, src/cff/cffload.c, src/cff/cffgload.c: updated
to mode the definition of encoding tables within "cffload.c" instead
of making them part of a shared header (causing problems in "multi"
builds)
for the Postscript hinter
* docs/BUGS: closed the AUTOHINT-NO-SBITS bug.
* src/pshinter/pshrec.c (t2_hint_stems), src/cff/cffobjs.h,
src/cff/cffobjs.c, src/cff/cffload.c, src/cff/cffload.h,
src/cff/cffgload.c, src/cff/cffgload.h, src/cff/cffdriver.c,
include/freetype/internal/cfftypes.h: added Postscript hinter support
to the CFF driver
* src/base/ftobjs.c (FT_Done_Library): fixed a stupid bug that crashed
the library on exit
on hinted glyphs..
* src/cid/cidgload.c, src/cid/cidobjs.c, src/cid/cidobjs.h,
src/cid/cidriver.c, include/freetype/internal/t1types.h: added
Postscript hinter support to the CID font driver !!
(FT_Load_Glyph): "fixed" the bug that prevented embedded bitmaps from
begin loaded when the auto-hinter is used.. This actually is a hack
but will be enough until the internal re-design scheduled for
FreeType 2.1
some of the exported functions should only be used by applications
that need to implement custom cache types
* src/truetype/ttgload.c: fixed a nasty bug that prevent composites
from loading correctly. Believe it or not, this was due to an invalid
macro definition !!
passing "-L/usr/lib" to gcc
* docs/FTL.TXT: simple fix (change "LICENSE.TXT" to "FTL.TXT")
* builds/unix/freetype2.m4: added autoconf macro, we need to install
it in $(prefix)/share/aclocal/freetype2.m4 but I didn't modified
builds/unix/install.mk yet..
GET_LongLE and GET_ULongLE which where incorrect (creating problems
in the pcf driver)..
* INSTALL: updated the instructions to build shared libraries with
Jam.. they were simply erroneous..
purposes..
* src/smooth/ftsmooth.c (ft_smooth_render): fixed a nasty hidden bug where
outline shifting wasn't correctly undone after bitmap rasterization. this
created problems with certain glyphs (like '"' of certain fonts..) and
the cache system..
* src/pshinter/pshalgo2.c (psh2_hint_table_init),
src/pshinter/pshalgo1.c (psh1_hint_table_init): removed compiler
warnings
* include/freetype/cache/*, src/cache/*: yet another massive rewrite of
the caching sub-system, in order to both increase performance and allow
simpler cache sub-classing. As an example, the code for the image and
sbit caches is now much simpler
I still need to update the documentation in www/freetype2/docs/cache.html
to reflect the new design though..
codes and LCIDs as found in MSDN (Passport SDK). Also added
comments about the meaning of bit 57 of OS/2 (TT_UCR_SURROGATES)
which with OpenType v.1.3 now means "there is a character beyond
FFFF in this font". Thanks to Detlef Wuerkner <TetiSoft@apg.lahn.de>
for noticing this.
routine that created nasty alignment artefacts.
* src/pshinter/pshrec.c, tests/gview.c: debugging updates..
* src/smooth/ftgrays.c: de-activated experimental gamme support,
apparently, "optimal" gamma tables depend on the monitor type,
resolution and general karma, so it's better to compute them outside
of the rasterizer itself..
Werner Lemberg