If HarfBuzz is enabled, the reverse character map generation now considers
GSUB entries when looking for glyphs that correspond to a code point.
* src/autofit/afadjust.c (af_all_glyph_variants_helper,
af_all_glyph_variants) [FT_CONFIG_OPTION_USE_HARFBUZZ]: New functions.
(af_reverse_character_map_new) [FT_CONFIG_OPTION_USE_HARFBUZZ]: Call new
code.
The CMake build uses `find_package` to look for dependencies. Before calling `find_package` it looks to see if the dependency was disabled. If not the associated `_FOUND` variable will be set. This value is then checked to determine if the dependency is added.
However `find_package(PNG)` calls `find_package(ZLIB)` within its find module. So in the case of `FT_DISABLE_ZLIB=TRUE` and `FT_DISABLE_PNG=FALSE` the `ZLIB_FOUND` value can be set and even though `FT_DISABLE_ZLIB` is turned on.
Unset the value of `ZLIB_FOUND` after the call to `find_package(PNG)` so the value is only set when `FT_DISABLE_ZLIB` is turned off.
This change comes along with 2a7bb4596f ans is only meant to reduce
pointer casting in the code.
* include/freetype/ftimage.h (FT_Outline): Do it.
* src/*: Update `FT_Outline` users.
In C it is undefined behavior to do arithmetic on a null pointer, including
adding zero. When using NotoSansKhmer[wdth,wght].ttf UBSAN produces a report
like
ttgxvar.c:1052:31: runtime error: applying zero offset to null pointer
when adding zero to `varData->deltaSet` (which is null) to produce `bytes`.
Protect against all the potential issues of this kind by returning early if
`varData->regionIdxCount == 0`.
* src/truetype/ttgxvar.c (tt_var_get_item_delta): early return on no regions
This doubles the number or allowed points, see
https://github.com/harfbuzz/harfbuzz/issues/4752
Although it is hardly practical to use more than 32767 points,
other font engines seem to support it.
* docs/CHANGES: Announce it.
* include/freetype/ftimage.h (FT_Outline): Do it and update limits.
* src/*: Update `FT_Outline` users.
Instead of validating variation axes in every access, OpenType specs
suggest that peak = 0 be used to tag invalid ranges. This implements
just that once during loading.
* src/cff/cffload.c (cff_blend_build_vector): Move the range checks...
(cff_vstore_load): ... here.
* src/truetype/ttgxvar.c (tt_var_get_item_delta): Ditto...
(tt_var_load_item_variation_store): ... ditto.
This should achieve quicker results for common cases.
* src/cff/cffload.c (cff_blend_build_vector): Rearrange conditionals.
* src/truetype/ttgxvar.c (tt_var_get_item_delta): Ditto.
* include/freetype/internal/t1types.h: Host PS_DesignMap and PS_Blend.
* include/freetype/ftmm.h: Host and document TT_MAX_MM_XXX.
* include/freetype/t1tables.h: Remove them from here.
`T1_FIELD_ZERO` is used to zero initialize a `T1_FieldRec`.
`T1_FIELD_ZERO` is currently initilizing `T1_FieldRec::location` with a
`T1_FieldType` and `T1_FieldRec::type` with a `T1_FieldLocation`. This
was detected with `-Wenum-conversion`.
* include/freetype/internal/psaux.h (T1_FIELD_ZERO): correct order of
initalizers
In 32 bit builds `FT_ULong` is 32 bits and can silently overflow when a
large number is read into one and then it is summed or multiplied with
another number. Checks for range overflow must be written so that they
themselves do not overflow. Also ensure that the table_size is always the
first part of the range check and consistently use `<` or `<=`.
* src/sfnt/ttcolr.c (tt_face_load_colr): Avoid overflow.
(find_base_glyph_v1_record): Remove old work-around.
Bug: https://issues.chromium.org/issues/41495455
Bug: https://issues.chromium.org/issues/40945818
FT_SqrtFixed (95b0fe2a6d) is faster and does not overflow.
* src/sdf/ftsdfcommin.h (square_root): Replace with a macro.
* src/sdf/ftsdfcommin.c (square_root): Remove function.
The upper limit of 4095 is implied by the SFNT header format
where the multiplication by 16 would overflow without it.
* src/sfnt/sfwoff.c (woff_open_font): Updated.
* src/sfnt/sfwoff2.c (woff2_open_font): Ditto.
The existing code already disallows zero table woff2 overall, but still
allows for individual CollectionFontEntry to create font instances with
zero tables. Such fonts are not useful so error early.
This also fixes an MSAN discovered issue where if a CollectionFontEntry
numTables is zero then the sfnt_header was not fully initialized.
* src/sfnt/sfwoff2.c (woff2_open_font): error on zero tables, always
initalize sfnt_header
Fixes: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=68384
Werner Lemberg