It might be surprising that FreeType does not have default ppem and
the size has to be set explicitly or face undefined behavior with
undefined variables and errors. This offers an alternative to
missing or zero scale by simply setting FT_LOAD_NO_SCALE. Defined
behavior is bettr than undefined one.
This is alternative to !132 and discussed in
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=43708
* src/base/ftobjs.c (FT_Load_Glyph): Deal with zero scale.
* include/freetype/freetype.h: Document it.
In the unlikely case the source is built with OpenWatcom's -ec?
switches to enforce a calling convention, the qsort() compare
function must still be set to __watcall.
* include/freetype/internal/compiler-macros.h (FT_COMPARE_DEF):
Updated.
* include/freetype/config/integer-types.h: Make sure `long long` is
used then available.
* include/freetype/internal/ftcalc.h (FT_MSB): Add Watcom C/C++ pragma.
The `hdmx` table is supposed to be sorted by ppem size, which
enables binary search. We also drop the check for the sufficient
length of the record because it is now enforced when the table
is loaded.
* include/freetype/internal/tttypes.h (TT_FaceRec): Store the `hdmx`
record pointers sorted by ppem instead of ppem's themselves.
* src/truetype/ttpload.c (tt_face_load_hdmx): Prudently sort records.
(tt_face_get_device_metrics): Implement binary search to retrieve
advances.
The `hdmx` matching can be done before the glyph is loaded.
* include/freetype/internal/tttypes.h (TT_LoaderRec): Add a field.
* src/truetype/ttgload.c (compute_glyph_metrics): Relocate the `hdmx`
code from here...
(tt_loader_init): ... to here, before the glyph is loaded.
==========================
Tag sources with `VER-2-11-1'.
* docs/VERSION.TXT: Add entry for version 2.11.1.
* docs/CHANGES, docs/release: Updated.
* README, src/base/ftver.rc, builds/windows/vc2010/index.html,
builds/windows/visualc/index.html, builds/windows/visualce/index.html,
builds/wince/vc2005-ce/index.html, builds/wince/vc2008-ce/index.html,
docs/freetype-config.1: s/2.11.0/2.11.1/, s/2110/2111/.
* include/freetype/freetype.h (FREETYPE_PATCH): Set to 1.
* builds/unix/configure.raw (version_info): Set to 24:1:18.
* CMakeLists.txt (VERSION_PATCH): Set to 1.
* builds/toplevel.mk (version_tag, CHANGELOG_SCRIPT): New variables.
(do-dist): Generate `ChangeLog` file with all commits since last release.
We really have to use double casts to avoid issues with C's and C++'s
signedness propagation rules in implicit casts.
Reported as
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=41178https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=41182
* include/freetype/config/public-macros.h (FT_STATIC_CAST,
FT_REINTERPRET_CAST): Modify macro to take two arguments.
Update all callers.
(FT_STATIC_BYTE_CAST): New macro.
* include/freetype/freetype.h (FT_ENC_TAG): Use `FT_STATIC_BYTE_CAST`.
* include/freetype/ftimage.h (FT_IMAGE_TAG): Ditto.
* include/freetype/fttypes.h (FT_MAKE_TAG): Ditto.
Use `FT_Tag` for casting.
* src/ftraster/ftmisc.h (FT_MAKE_TAG): Removed, no longer needed.
(FT_STATIC_BYTE_CAST): New macro.
* src/smooth/ftgrays.c (FT_STATIC_CAST): Replace with...
(FT_STATIC_BYTE_CAST): ... this.
Many FreeType clients use C++. However `g++ -Wold-style-cast` warns for
macros with C-style casts even for system header files; this also affects
directories included with `-isystem`. While this could be seen as a problem
with g++, the problem is more a philosophical one: Over the time, C and C++
diverged more and more, and some features of C are no longer the 'right'
solution in C++.
* include/freetype/config/public-macros.h (FT_STATIC_CAST,
FT_REINTERPRET_CAST): New macros.
* include/freetype/freetype.h (FT_ENC_TAG, FT_LOAD_TARGET_,
FT_LOAD_TARGET_MODE): Use `FT_STATIC_CAST`.
Correctly handle negative 'signed char' input.
* include/freetype/ftimage.h (FT_IMAGE_TAG): Ditto.
* include/freetype/fttypes.h (FT_MAKE_TAG, FT_BOOL): Ditto.
* include/freetype/ftmodapi.h (FT_FACE_DRIVER_NAME): Use
`FT_REINTERPRET_CAST`.
* src/smooth/ftgrays.c (FT_STATIC_CAST)[STANDALONE_]: New macro.
[!STANDALONE]: Include `FT_CONFIG_CONFIG_H`.
Fixes#1116.
DLG_STATIC is intended to disable Windows DLL linking attributes.
It does not hurt to define it explicitly when we wrap DLG code.
This fixes tons of LNK4286 and C4273 warnings from MSVC if we
forget to define DLG_STATIC as a compiler option.
* builds/windows/vc2010/freetype.vcxproj: Remove DLG_STATIC option.
* src/dlg/dlgwrap.c [FT_DEBUG_LOGGING]: Define DLG_STATIC.
* include/freetype/internal/ftdebug.h [FT_DEBUG_LOGGING]: Ditto.
FT_QNEW_ARRAY and FT_QRENEW_ARRAY were using the non-Q
FT_MEM_NEW_ARRAY and FT_MEM_RENEW_ARRAY. Change these to use the Q
versions. Also fix the one issue discovered in tt_face_load_name
where table->names is created with FT_QNEW_ARRAY but the extra
string member is not initialized to NULL.
* include/freetype/internal/ftmemory.h (FT_Q(RE)NEW_ARRAY):
Use FT_MEM_Q(RE)NEW_ARRAY as needed.
* src/sfnt/ttload.c (tt_face_load_name): Initialize `entry->string`.
Signed 24-bit values are extremely rare. FreeType only reads them in
PFR fonts with bitmap strikes conditionally. They have not been seen
in the known fonts. That is why this bug could never be discovered.
`FT_FRAME_OFF3` propagates sign correctly.
* include/freetype/internal/ftstream.h (FT_PEEK_OFF3, FT_PEEK_OFF3_LE):
Propagate sign into 32-bit value.
(FT_GET_OFF3, FT_READ_OFF3): Needed fixing but removed as unused.
* src/base/ftstream.c (FT_Stream_ReadUShort, FT_Stream_ReadUOffset,
FT_Stream_ReadULong and their LE variants): Remove unnecessary
initialization and slightly refactor.
(FT_Stream_GetByte, FT_Stream_ReadByte): Rename to return unsigned
value and align with sister functions.
* include/freetype/internal/ftstream.h (FT_Stream_GetByte,
FT_Stream_ReadByte): Update prototypes and caller macros.
MSVC, for example, used `long long` even without full C99 support.
* include/freetype/config/ftstdlib.h: Check if `long long` limits are
defined in <limits.h>.
* include/freetype/config/integer-types.h: Check `long long` size and
use it to typedef FT_Int64.
The optional 'COLR' v1 glyph-specific clip box helps upstream graphics
libraries allocate a sufficiently large bitmap for a glyph without having to
traverse the glyph graph for that. See
https://github.com/googlefonts/colr-gradients-spec/issues/251
for background on the introduction of this specification change.
* include/freetype/ftcolor.h (FT_ClipBox): New structure.
(FT_Get_Color_Glyph_ClipBox): New function declaration.
* include/freetype/internal/sfnt.h (TT_Get_Color_Glyph_ClipBox_Func):
New function type.
(SFNT_Interface, FT_DEFINE_SFNT_INTERFACE): Use it.
* src/base/ftobjs.c (FT_Get_Color_Glyph_ClipBox): New function to link API
with SFNT implementation.
* src/sfnt/sfdriver.c (sfnt_interface): Updated.
* src/sfnt/ttcolr.c (Colr): New field `clip_list`.
(tt_face_load_colr): Parse global clip list offset.
(tt_face_get_color_glyph_clipbox): New function to find the clip box for a
glyph id from the clip list array.
* src/sfnt/ttcolr.h: Updated.
* src/sfnt/ttcolr.c (read_paint): PaintSweepGradient follows other
spec changes and now has the angles specified as F2DOT14, reflect
that in the implementation.
* include/freetype/ftcolor.h (FT_PaintSweepGradient): Update
documentation.
* src/sfnt/ttcolr.c (read_paint): Implement spec changes around
PaintSkew, PaintSkewAroundCenter. Update parsing to read shorter
values as changed in the spec.
* include/freetype/ftcolor.h (FT_PaintSkew): Update documentation.
* src/sfnt/ttcolr.c (read_paint): Implement spec change where
PaintRotate and PaintRotateAroundCenter were split for a more
compact format definition. Update parsing to read shorter values
as changed in the spec.
* include/freetype/ftcolor.h (FT_PaintRotate): Update documentation.
==========================
Tag sources with `VER-2-11-0'.
* docs/VERSION.TXT: Add entry for version 2.11.0.
* docs/CHANGES: Updated.
* README, src/base/ftver.rc, builds/windows/vc2010/index.html,
builds/windows/visualc/index.html,
builds/windows/visualce/index.html,
builds/wince/vc2005-ce/index.html,
builds/wince/vc2008-ce/index.html, docs/freetype-config.1:
s/2.10.4/2.11.0/, s/2104/2110/.
* include/freetype/freetype.h (FREETYPE_MINOR): Set to 11.
(FREETYPE_PATCH): Set to 0.
* builds/unix/configure.raw (version_info): Set to 24:0:18.
* CMakeLists.txt (VERSION_MINOR): Set to 11.
(VERSION_PATCH): Set to 0.
* builds/toplevel.mk (dist): Ignore more git-related files.
I am currently trying to compile FreeType for CHERI-extended ISAs
(CHERI-RISC-V and Arm's Morello), but I am getting compiler warnings
from the `FT_UINT_TO_POINTER` macro. When compiling with the CHERI
Clang compiler, not using `uinptr_t` for casts between integers an
pointers results in the following `-Werror` build failures:
```
In file included from .../src/truetype/truetype.c:22:
.../src/truetype/ttgload.c:1925:22: error:
cast from provenance-free integer type to pointer type will
give pointer that can not be dereferenced
[-Werror,-Wcheri-capability-misuse]
node->data = FT_UINT_TO_POINTER( glyph_index );
^
.../include/freetype/internal/compiler-macros.h:79:34: note:
expanded from macro 'FT_UINT_TO_POINTER'
```
* include/freetype/internal/compiler-macros.h (FT_UINT_TO_POINTER):
The ISO C standard compliant fix for this would be to use
`uintptr_t` from `stdint.h`, but I am not sure if this is supported
by the minimum compiler version. Therefore, use the
compiler-defined `__UINTPTR_TYPE__` macro (supported in GCC 4.6+ and
Clang since about 3.0) before checking for `_WIN64` and falling back
to `unsigned long`.
This was already true (though undocumented) most of the time, but
not if `FT_NEW` inside `FT_Stream_New` failed or if the
`FT_OPEN_XXX` flags were bad.
Normally, `FT_Open_Face` calls `FT_Stream_New`, which returns the
user-supplied stream unchanged, and in case of any subsequent error
in `FT_Open_Face`, the stream is closed via `FT_Stream_Free`.
Up to now, however, `FT_Stream_New` allocates a new stream even if
it is already given one by the user. If this allocation fails, the
user-supplied stream is not returned to `FT_Open_Face` and never
closed. Moreover, the user cannot detect this situation: all they
see is that `FT_Open_Face` returns `FT_Err_Out_Of_Memory`, but that
can also happen after a different allocation fails within the main
body of `FT_Open_Face`, when the user's stream has already been
closed by `FT_Open_Face`. It is plausible that the user stream's
`close` method frees memory allocated for the stream object itself,
so the user cannot defensively free it upon `FT_Open_Face` failure
lest it ends up doubly freed. All in all, this ends up leaking the
memory/resources used by user's stream.
Furthermore, `FT_Stream_New` simply returns an error if the
`FT_OPEN_XXX` flags are unsupported, which can mean either an
invalid combination of flags or a perfectly innocent
`FT_OPEN_STREAM` on a FreeType build that lacks stream support.
With this patch, the user-supplied stream is closed even in these
cases, so the user can be sure that if `FT_Open_Face` failed, the
stream is definitely closed.
* src/base/ftobjs.c (FT_Stream_New): Don't allocate a buffer
unnecessarily.
Move error-handling code to make the control flow more obvious.
Close user-supplied stream if the flags are unsupported.
`FT_Stream_Open` always sets `pathname.pointer`, so remove the
redundant (re)assignment. None of the `FT_Stream_Open...` functions
uses `stream->memory`, so keep just one assignment at the end,
shared among all possible control flow paths.
('Unsupported flags' that may need a stream closure can be either an
invalid combination of multiple `FT_OPEN_XXX` mode flags or a clean
`FT_OPEN_STREAM` flag on a FreeType build that lacks stream
support.)
The three modes are mutually exclusive, and the documentation of the
`FT_OPEN_XXX` constants notes this. However, there was no check to
validate this in the code, and the documentation on `FT_Open_Args`
claimed that the corresponding bits were checked in a well-defined
order, implying it was valid (if useless) to specify more than one.
Ironically, this documented order did not agree with the actual
code, so it could not be relied upon; hopefully, nobody did this and
nobody will be hurt by the new validation.
Even if multiple mode bits were allowed, they could cause memory
leaks: if both `FT_OPEN_STREAM` and `stream` are set along with
either `FT_OPEN_MEMORY` or `FT_OPEN_PATHNAME`, then `FT_Stream_New`
allocated a new stream but `FT_Open_Face` marked it as an 'external'
stream, so the stream object was never released.
* src/base/ftobjs.c (FT_Stream_New): Reject incompatible
`FT_OPEN_XXX` flags.
This feature was always experimental, and probably nevery worked
properly. This patch completely removes it from the source code,
except for a documentation block describing it for historical
purpose.
