Modern color fonts often contain both an 'SVG' and 'COLR' table. FreeType
always preferred 'SVG' over 'COLR' (this was a design decision), however,
this might not be the right choice for the user. The new flags makes
FreeType ignore the 'SVG' table while loading a glyph.
Fixes#1229.
* include/freetype/freetype.h (FT_LOAD_NO_SVG): New macro.
* src/base/ftobjs.c (FT_Load_Glyph), src/cff/cffgload.c (cff_slot_load),
src/truetype/ttgload.c (TT_Load_Glyph): Use it.
Modern compilers get more insistent on that...
* include/freetype/internal/compiler-macros.h (FALL_THROUGH): Define.
* src/*: Use it instead of `/* fall through */` comments.
Otherwise we get zillions of clang 15 warnings.
* src/autofit/afcjk.c, src/autofit/afhints.c, src/autofit/aflatin.c,
src/base/ftobjs.c, src/base/ftoutln.c, src/cff/cffparse.c,
src/raster/ftraster.c, src/sfnt/pngshim.c, src/truetype/ttgload.c,
src/truetype/ttgxvar.c, src/truetype/ttobjs.c, src/type1/t1gload.c: Use
`double` cast in debugging and tracing macros.
In `open_face_from_buffer` it is possible that a driver is requested but
FreeType was built without the requested module. Return an error in this
case to indicate that the request could not be satisfied, rather than trying
all existing driver modules.
* src/base/ftobjs.c (open_face_from_buffer): Return `FT_Err_Missing_Module`
if a driver is specified but not found.
The documentation for `FT_StreamRec::memory` states that it 'shouldn't be
touched by stream implementations'. This is true even for internal
implementations of the 'close' callback, since it is not guaranteed that
`memory` will even be set when the 'close' callback occurs.
* src/base/ftobjs.c (new_memory_stream): stash current `memory` in
`stream->descriptor`.
(memory_stream_close): Use it.
The `FT_Open_Face` documentation states
> If `FT_OPEN_STREAM` is set in `args->flags`, the stream in `args->stream`
> is automatically closed before this function returns any error (including
> `FT_Err_Invalid_Argument`).
However, if the user provides a stream in `args.stream` with
`FT_OPEN_STREAM` set and a `close` function, but then for some reason passes
NULL for `aface` and a non-negative `face_index`, the error
`Invalid_Argument` is returned but the `close` callback will not be called
on the user-provided stream. This may cause resource leaks if the caller is
depending on the `close` callback to free resources.
The difficulty is that a user may fill out a `FT_StreamRec` and pass its
address as `args.stream`, but the stream isn't really 'live' until
`FT_Stream_New` is called on it (and `memory` is set). In particular, it
cannot really be cleaned up properly in `ft_open_face_internal` until the
stream pointer has been copied into the `stream` local variable.
* src/base/ftobj.c (ft_open_face_internal): Ensure that user-provided
`args.stream.close` is called even with early errors.
`open_face_from_buffer` allocates a new `FT_Stream` to pass to
`ft_open_face_internal`. Because this is an `FT_OPEN_STREAM`,
`ft_open_face_internal` will mark this as an 'external stream', which the
caller must free. However, `open_face_from_buffer` cannot directly free it
because the stream must last as long as the face. There is currently an
attempt at this by clearing the 'external stream' bit after
`open_face_from_buffer` returns successfully. However, this is too late as
the original stream may have already been closed and the stream on the face
may not be the same stream as originally passed.
It is tempting to use `FT_OPEN_MEMORY` and let `ft_open_face_internal`
create the stream internally. However, with this method there is no means
to pass through a 'close' function to the created stream to free the
underlying data, which must be owned by the stream.
A possibility is to check on success if the stream of the face is the same
as the original stream. If it is then unset the external flag. If not,
then free the original stream. Unfortunately, while no current
implementation does so, it is possible that the face still has the original
stream somewhere other than as the `FT_FaceRec::stream`. The stream needs
to remain available for the life of the face or until it is closed,
whichever comes earlier.
The approach taken here is to let the stream own itself. When the stream is
closed it will free itself.
* src/base/ftobjs.c (memory_stream_close): Free `stream`.
(open_face_from_buffer): Simplify error handling, since
`ft_open_face_internal` always closes `args.stream` on any error.
Fixes: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=54930
In `open_face` the initial stream is set on the face, along with the
information about if FreeType is the owner of the stream object itself. The
loaders may in the course of their work replace this stream with a new
stream (as is the case for 'woff' and 'woff2'), which may have a different
ownership than the initial stream object (likely the original stream object
is owned by the user and is external, while the new stream object is created
internally to FreeType and is internal). When the stream is replaced, the
face's flags are updated with the new ownership status.
However, `open_face` cannot itself free this stream as its caller
`ft_open_face_internal` is responsible for this. In addition, in the case
of an error `open_face` cannot return an actual face with the new stream and
its ownership status to the caller. As a result, it must pass this
information back to the caller as a sort of "failed face" so that the caller
can clean up.
`open_face` was already passing back the new stream but was not passing back
the stream ownership information. As a result the stream may not have been
free'd when needed.
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=54700
* src/base/ftobjs.c (open_face): Pass back the ownership information as
well.
(ft_open_face_internal): Updated.
The division-by-zero might happen in broken fonts (see #1194).
Instead of returning a huge number from FT_DivFix and failing
to scale later, we now bail immediately.
This follows similar code in `cff_slot_done`.
* src/base/ftobjs.c (ft_glyphslot_done), src/type1/t1objs.c
(T1_GlyphSlot_Done): Check `internal` pointer.
The Type1 problems was reported as
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=50057.
This issue was discovered with an SVG based font with some documents
compressed and other uncompressed. After loading the first compressed
document the ownership flag on the glyph slot was set to true but never
set to false. As a result after loading a compressed document a glyph
from an uncompressed document would load fine, but when this glyph slot
was cleared it would try to free its document resulting in a wild free.
* src/base/ftobjs.c (ft_glyphslot_clear): clear correct flags
Fixes: #1162
* include/freetype/config/ftheader.h (FT_OTSVG_H): New macro.
* include/freetype/freetype.h (FT_FACE_FLAG_SVG, FT_HAS_SVG): New macros.
(FT_LOAD_SVG_ONLY): New internal macro.
* include/freetype/ftimage.h (FT_Glyph_Format): New enumeration value
`FT_GLYPH_FORMAT_SVG`.
* include/freetype/internal/ftobjs.h (FT_GLYPH_OWN_GZIP_SVG): New macro.
* include/freetype/internal/fttrace.h: Add `ttsvg` for `ttsvg.c`.
* include/freetype/internal/sfnt.h(load_svg, free_svg, load_svg_doc): New
functions.
* include/freetype/internal/tttypes.h (TT_FaceRec): Add `svg` for
the SVG table.
* include/freetype/otsvg.h (FT_SVG_DocumentRec): New structure to hold the
SVG document and other necessary information of an OT-SVG glyph in a glyph
slot.
* include/freetype/tttags.h (TTAG_SVG): New macro.
* src/base/ftobjs.c: Include `otsvg.h`.
(ft_glyphslot_init): Allocate `FT_SVG_DocumentRec` in `slot->other`
if the SVG table exists.
(ft_glyphslot_clear): Free it upon clean-up if it is a GZIP compressed
glyph.
(ft_glyphslot_done): Free the document data if it is a GZIP compressed
glyph.
(FT_Load_Glyph): Don't auto-hint SVG documents.
* src/cache/ftcbasic.c (ftc_basic_family_load_glyph): Add support for
FT_GLYPH_FORMAT_SVG.
* src/sfnt/rules.mk (SFNT_DRV_SRC): Add `ttsvg.c`.
* src/sfnt/sfdriver.c: Include `ttsvg.h`.
(sfnt_interface): Add `tt_face_load_svg`, `tt_face_free_svg` and
`tt_face_load_svg_doc`.
* src/sfnt/sfnt.c: Include `ttsvg.c`.
* src/sfnt/sfobjs.c (sfnt_load_face, sfnt_done_face): Add code to load and
free data of the the SVG table.
* src/sfnt/ttsvg.c: New file, implementing `tt_face_load_svg`,
`tt_face_free_svg` and `tt_face_load_svg_doc`.
* src/sfnt/ttsvg.h: Declarations of the SVG functions in
`ttsvg.c`.
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.
* src/base/ftobjs.c (FT_Get_Paint): Operator has equivalent nested operands.
* src/bdf/bdflib.c (_bdf_add_property): Value stored to `fp` is never read.
* src/sdf/ftbsdf.c (bsdf_init_distance_map): Value stored to `pixel` is
never read.
* src/sdf/ftsdf.c (split_sdf_shape): Value stored to `error` is never read.
With Windows memory management tracking heap, it is important to use
it during the stream opening fallback. In Unix, the argument is
unused, but it is better to set it correctly.
* src/base/ftobjs.c (FT_Stream_New): Set memory before calling
`FT_Stream_Open`.
* builds/windows/ftsystem.c, builds/unix/ftsystem.c (FT_Stream_Open,
ft_close_stream_by_free): Call `ft_alloc` and `ft_free` with proper
memory argumment.
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.
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.)