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.)
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.
* src/base/ftobjs.c (open_face_PS_from_sfnt_stream,
Mac_Read_sfnt_Resource): Do not zero out the buffer.
* src/base/ftmac.c (FT_New_Face_From_SFNT, read_lwfn): Ditto.
* src/base/ftrfork.c (raccess_make_file_name,
raccess_guess_darwin_hfsplus, raccess_guess_darwin_newvfs): Ditto.
* src/base/ftobjs.c (ft_glyphslot_clear): This function is intended
to reset all the values of a glyph slot. However, it was not
resetting the values of the advances and `glyph_index`. Reset the
advances and `glyph_index` to zero.
* include/freetype/freetype.h (FT_Get_Color_Glyph_Paint):
Additional function argument root_transform to control whether
root transform should be returned.
(FT_OpaquePaint): Additional tracking field to denote whether
root transform is to be returned.
* include/freetype/internal/sfnt.h
(TT_Get_Color_Glyph_Paint_Func): Propagate additional argument.
* src/base/ftobjs.c (FT_Get_Color_Glyph_Paint): Ditto.
* src/sfnt/ttcolr.c (tt_face_get_colr_glyph_paint): Return root
transform reflecting the size and tranform configured on
FT_Face.
(read_paint): Initialize and track status of insert_root_transform
flag.
* src/base/ftobjs.c (FT_Get_Color_Glyph_Paint, FT_Get_Paint_Layers,
FT_Get_Paint, FT_Get_Colorline_Stops): Add basic sanity checks,
check for existence of `FT_Face`, check arguments and delegate calls
for the respective 'COLR' v1 API to the SFNT driver.
* include/freetype/freetype.h (FT_Get_Color_Glyph_Paint): New method
for retrieving the root paint object for a color glyph by specifying
a glyph ID.
(FT_Get_Paint_Layers): New method for retrieving the layers of a
`PaintColorGlyph`.
(FT_Get_ColorLine_Stops): New method for retrieving the stops of a
color.
(FT_Get_Paint): New method for resolving an `FT_OpaquePaint` into an
`FT_COLR_Paint` object.
* src/base/ftobjs.c (FT_Render_Glyph_Internal): Do not return if the
glyph's slot format is `FT_GLYPH_FORMAT_BITMAP`. The forthcoming
'bsdf' renderer will require bitmaps for processing.
* src/base/ftobjs.c (ft_add_renderer, ft_remove_renderer): Remove
renderer's glyph format check before adding and removing them. The
'bsdf' renderer will have a format `FT_GLYPH_FORMAT_BITMAP`.
* include/freetype/internal/ftdebug.h: Added dlg's header files.
(FT_LOG): New macro to redirect trace logs to dlg's API's whenever
`FT_LOGGING' is defined.
(ft_logging_init, ft_logging_deinit): New functions to handle
initialization and uninitialization of logging related variables.
(ft_log_handler): New function to handle logs of FreeType.
* src/base/ftdebug.c: Add necessary logging related variables.
(ft_logging_init, ft_logging_deinit, ft_log_handler): Add function
definitions.
* src/base/ftinit.c (FT_Init_FreeType) [FT_LOGGING]: Call
`ft_logging_init`.
(FT_Done_FreeType) [FT_LOGGING]: Call `ft_logging_deinit`.
* src/base/ftobjs.c (FT_New_Library): Call `ft_debug_init` only if
`FT_LOGGING` is not defined.
* src/base/ftobjs.c (FT_New_Size): Avoid trying to free
`size->internal`, unless `size' has been allocated. This
mistake appeared in the fix for 58611.
We no longer have to take care of the 8.3 file name limit; this
allows us (a) to introduce longer, meaningful file names, and (b) to
avoid macro names in `#include' lines altogether since some
compilers (most notably Visual C++) doesn't support this properly.
*/*: Replace
#include FOO_H
with
#include <freetype/foo.h>
or something similar. Also update the documentation.
Before this commit we had code like
(FT_Bool)( globals->glyph_styles[gindex] & 0x8000)
Since `FT_Bool' is defined to be an `unsigned char', the code
evaluated to something like
(unsigned char)( 0x8532 & 0x8000)
which in turn expanded to
(unsigned char)( 0x8000)
and finally yielded 0x00 – i.e., false – not as expected.
Problem reported and analyzed by Tony Smith <tony.smith@macro4.com>.
* include/freetype/fttypes.h (FT_BOOL): Add a comparison against
zero so that we always have a Boolean expression.
*/*: Replace castings to `FT_Bool' with calls to `FT_BOOL' where
possible.
For bitmap fonts, `FT_Load_Glyph' should either return an error or
not set the format to `FT_GLYPH_FORMAT_OUTLINE'. However, in this
case `FT_Load_Glyph' calls into the auto-hinter which calls back
into `FT_Load_Glyph' with `FT_LOAD_NO_SCALE' in the flags, which
marks the glyph as `FT_GLYPH_FORMAT_OUTLINE' with an empty path
(even though it doesn't have any path). It appears that the
auto-hinter should not be called when the face doesn't have
outlines. The current test for using the auto-hinter in
`FT_Load_Glyph' checks if the driver supports scalable outlines, but
not if the face supports scalable outlines.
* src/base/ftobjs.c (FT_Load_Glyph): Directly check whether we have
scalable outlines.
* include/freetype/internal/ftobjs.h (ft_glyphslot_preset_bitmap):
Change return type.
* src/base/ftobjs.c (ft_glyphslot_preset_bitmap): Return the bitmap
size assessment.
* src/raster/ftrend1.c (ft_raster1_render): Use it to refuse the
rendering of enourmous or far-fetched outlines.
* src/smooth/ftsmooth.c (ft_smooth_render_generic): Ditto.
Werner Lemberg