The main cycle in `blit_sbit' makes too many iterations: it actually
needs the count of lines in the source bitmap rather than in the
target image.
* src/sfnt/ttsbit.c (blit_sbit) [FT_CONFIG_OPTION_OLD_INTERNALS]:
Add parameter `source_height' and use it for main loop.
(Load_SBit_Single) [FT_CONFIG_OPTION_OLD_INTERNALS]: Updated.
* src/sfnt/sfobjs.c (sfnt_load_face): Test for bitmap strikes before
setting metrics and bbox values. This ensures that the check for a
font with neither a `glyf' table nor bitmap strikes can be performed
early enough to set metrics and bbox values too.
* include/freetype/config/ftconfig.h (FT_MulFix_i386): Make
assembler code work with gcc 2.95.3 (as used by the Haiku project).
Add `cc' register to the clobber list.
=========================
Tag sources with `VER-2-3-8'.
* docs/VERSION.DLL: Update documentation and bump version number to
2.3.8.
* README, Jamfile (RefDoc), builds/win32/visualc/index.html,
builds/win32/visualc/freetype.dsp,
builds/win32/visualc/freetype.vcproj,
builds/win32/visualce/index.html,
builds/win32/visualce/freetype.dsp,
builds/win32/visualce/freetype.vcproj: s/2.3.7/2.3.8/, s/237/238/.
* include/freetype/freetype.h (FREETYPE_PATCH): Set to 8.
* builds/unix/configure.raw (version_info): Set to 9:19:3.
* docs/release: Updated.
* src/psaux/psobjs.c (ps_parser_load_field_table): Don't handle
`count_offset' if it is zero (i.e., unused). Otherwise, the first
element of the structure which holds the data is erroneously
modified. Problem reported by Chi Nguyen <chint@necsv.com>.
* builds/unix/configure.raw: Don't call AC_CANONICAL_BUILD and
AC_CANONICAL_TARGET and use $host_os only. A nice explanation for
this change can be found at
http://blog.flameeyes.eu/s/canonical-target.
From Savannah patch #6712.
src/smooth/ftgrays.c, src/base/ftobjc.s, src/sfobjs.c:
s/_Err_Bad_Argument/_Err_Invalid_Argument/. The former is for
errors in the bytecode interpreter only.
extern const FT_Module_Class
(or similar for C++). However, the actual types of the variables
being declared are often different, e.g., FT_Driver_ClassRec or
FT_Renderer_Class. (Some are, indeed, FT_Module_Class.)
This works with most C compilers (since those structs begin with an
FT_Module_Class struct), but technically it's undefined behavior.
To quote the ISO/IEC 9899:TC2 final committee draft, section 6.2.7
paragraph 2:
All declarations that refer to the same object or function shall
have compatible type; otherwise, the behavior is undefined.
(And they are not compatible types.)
Most C compilers don't reject (or even detect!) code which has this
issue, but the GCC LTO development branch compiler does. (It
outputs the types of the objects while generating .o files, along
with a bunch of other information, then compares them when doing the
final link-time code generation pass.)
Patch from Savannah bug #25133.
* src/base/ftinit.c (FT_USE_MODULE): Include variable type.
* builds/amiga/include/freetype/config/ftmodule.h,
include/freetype/config/ftmodule.h, */module.mk: Updated to declare
pass correct types to FT_USE_MODULE.
Werner Lemberg