Problem reported by Tavis Ormandy <taviso@google.com>.
* src/smooth/ftsmooth.c (ft_smooth_render_generic): Don't allow
`width' or `pitch' to be larger than 0xFFFF.
* include/freetype/ftcid.h (FT_Get_CID_Is_Internally_CID_keyed,
FT_Get_CID_From_Glyph_Index): New functions.
* include/freetype/internal/services/svcid.h
(FT_CID_GetIsInternallyCIDKeyedFunc,
FT_CID_GetCIDFromGlyphIndexFunc): New function typedefs.
(CID Service): Use them.
* src/base/ftcid.c: Include FT_CID_H.
(FT_Get_CID_Is_Internally_CID_keyed, FT_Get_CID_From_Glyph_Index):
New functions.
* src/cff/cffdrivr.c (cff_get_is_cid, cff_get_cid_from_glyph_index):
New functions.
(cff_service_cid_info): Add them.
* src/cff/cffload.c (cff_font_load): Don't free `font->charset.sids'
-- it is needed for access as a CID-keyed font. It gets deleted
later on.
* src/cid/cidriver.c (cid_get_is_cid, cid_get_cid_from_glyph_index):
New functions.
(cid_service_cid_info): Add them.
* docs/CHANGES: Updated.
We now simply check for a valid `offset', no longer handling `delta
= 1' specially.
* src/sfnt/ttcmap.c (tt_cmap4_validate): Don't check `delta' for
last segment.
(tt_cmap4_set_range, tt_cmap4_char_map_linear,
tt_cmap4_char_map_binary): Check offset.
This patch fixes the following problems in ttsbit0.c:
. Bitmaps for compound glyphs were never allocated.
. `SBitDecoder' refused to load metrics if some other metrics have
already been loaded. This condition certainly makes no sense for
recursive calls, so I've just disabled it. Another possibility
would be resetting `decoder->metrics_loaded' to false before
loading each composite component. However, we must restore the
original metrics after finishing the recursion; otherwise we can
get a misaligned glyph.
. `tt_sbit_decoder_load_bit_aligned' incorrectly handled `x_pos',
causing some glyph components to be shifted too far to the right
(especially noticeable for small sizes).
Note that support for grayscale bitmaps (not necessarily compound) is
completely broken in ttsbit0.c.
* src/sfnt/tt_sbit_decoder_load_metrics: Always load metrics.
(tt_sbit_decoder_load_bit_aligned): Handle `x_pos' correctly in case
of `h == height'.
(tt_sbit_decoder_load_compound): Reset metrics after loading
components.
Allocate bitmap.
Closes Savannah BUG #25750
* src/sfnt/ttkern.c (tt_face_get_kerning): fix a bug
where a malformed table would be succesfully loaded but
later crash the engine during parsing.
Instead, we define a new internal PS_FontExtraRec structure to
hold the additionnal field, then place it in various internal
positions of the corresponding FT_Face derived objects.
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.
* 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>.
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.
