We never have to deal with composite glyphs in the autohinter, as
those will be loaded into FORMAT_OUTLINE by the recursed
`FT_Load_Glyph' function.
In the rare cases that FT_LOAD_NO_RECURSE is set, it will imply
FT_LOAD_NO_SCALE as per `FT_Load_Glyph', which then implies
FT_LOAD_NO_HINTING:
/* resolve load flags dependencies */
if ( load_flags & FT_LOAD_NO_RECURSE )
load_flags |= FT_LOAD_NO_SCALE |
FT_LOAD_IGNORE_TRANSFORM;
if ( load_flags & FT_LOAD_NO_SCALE )
{
load_flags |= FT_LOAD_NO_HINTING |
FT_LOAD_NO_BITMAP;
load_flags &= ~FT_LOAD_RENDER;
}
and as such the auto-hinter is never called. Thus, the recursion in
`af_loader_load_g' never actually happens. So remove the depth
counter as well.
* src/autofit/afloader.c (af_loader_load_g): Remove `depth'
parameter.
<FT_GLYPH_FORMAT_COMPOSITE>: Remove associated code.
(af_loader_load_glyph): Updated.
Apparently `ras.cProfile' might be uninitialized. This will be the
case if `ras.top == ras.cProfile->offset', as can be seen in
`End_Profile'. The overshoot code introduced in a change `Fix B/W
rasterization of subglyphs with different drop-out modes.' (from
2009-06-18) violated this, accessing `ras.cProfile->flags'
unconditionally just before calling `End_Profile' (which then
detected that `cProfile' is uninitialized and didn't touch it).
This was harmless, and was not detected by valgrind before because
the objects were allocated on the `raster_pool', which was always
initialized. With recent change to allocate raster buffers on the
stack, valgrind now reported this invalid access.
* src/raster/ftraster.c (Convert_Glyph): Don't access an
uninitialized `cProfile'.
Looks like `ras.span_y' could always be used without initialization.
This was never detected by valgrind before because the library-wide
`raster_pool' was used for the worker object and `raster_pool' was
originally zero'ed. But subsequent reuses of it were using `span_y'
uninitialized. With the recent change to not use `render_pool' and
allocate worker and buffer on the stack, valgrind now detects this
uninitialized access.
* src/smooth/ftgrays.c (gray_raster_render): Initialize
`ras.span_y'.
It's unused after the following commits:
[raster] Allocate render pool for mono rasterizer on the stack.
[raster] Remove 5-level gray AA mode from monochrome rasterizer.
The value of FT_RENDER_POOL_SIZE still serves the purpose it used to
serve, which is, to adjust the pool size. But the pool is now
allocated on the stack on demand.
* src/base/ftobjs.c (FT_New_Library, FT_Done_Library): Implement.
Instead of keeping `library->renderers' in a MRU order, just leave
it as-is. The MRU machinery wasn't thread-safe.
With this patch, rasterizing glyphs from different faces from
different threads doesn't fail choosing rasterizer
(FT_Err_Cannot_Render_Glyph).
Easiest to see that crash was to add a `printf' (or otherwise let
thread yield in FT_Throw with debugging enabled).
* src/base/ftobjs.c (FT_Render_Glyph_Internal), src/base/ftoutln.c
(FT_Outline_Render): Don't call `FT_Set_Renderer'.
Instead of using the `render_pool' member of `FT_Library' that is
provided down to the rasterizer, completely ignore that and allocate
needed objects on the stack instead.
With this patch, rasterizing glyphs from different faces from
different threads doesn't crash in the monochrome rasterizer.
* src/raster/ftraster.c (black_TRaster): Remove `buffer',
`buffer_size', and `worker' members.
(ft_black_render): Create `buffer' locally.
(ft_black_reset): Updated.
It was off by default and couldn't be turned on at runtime. And the
smooth rasterizer superceded it over ten years ago. No point in
keeping. Comments suggested that it was there for compatibility
with FreeType 1.
550 lines down.
* src/raster/ftraster.c (FT_RASTER_OPTION_ANTI_ALIASING,
RASTER_GRAY_LINES): Remove macros and all associated code.
(black_TWorker): Remove `gray_min_x' and `gray_max_x'.
(black_TRaster): Remove `grays' and `gray_width'.
(Vertical_Sweep_Init, Vertical_Sweep_Span, Vertical_Sweep_Drop,
ft_black_render): Updated.
* src/raster/ftrend1.c (ft_raster1_render): Simplify code.
(ft_raster5_renderer_class): Removed.
Previously the code had stipulation for using a per-TT_Size exec
context if `size->debug' was true. But there was no way that
`size->debug' could *ever* be true. As such, the code was always
using the singleton `TT_ExecContext' that was stored in `TT_Driver'.
This was, clearly, not threadsafe.
With this patch, loading glyphs from different faces from different
threads doesn't crash in the bytecode loader code.
* src/truetype/ttobjs.h (TT_SizeRec): Remove `debug' member.
(TT_DriverRec): Remove `context' member.
* src/truetype/ttobjs.c (tt_size_run_fpgm, tt_size_run_prep): Remove
`TT_ExecContext' code related to a global `TT_Driver' object.
(tt_driver_done): Don't remove `TT_ExecContext' object here but ...
(tt_size_done_bytecode): ... here.
(tt_driver_init): Don't create `TT_ExecContext' object here but ...
(tt_size_init_bytecode): ... here, only on demand.
* src/truetype/ttinterp.c (TT_Run_Context): Remove defunct debug
code.
(TT_New_Context): Remove `TT_ExecContext' code related to a global
`TT_Driver' object.
* src/truetype/ttinterp.h: Updated.
* src/truetype/ttgload.c (TT_Hint_Glyph, tt_loader_init): Updated.
Stop sharing a global `AF_Loader'. Allocate one on the stack during
glyph load.
Right now this results in about 25% slowdown, to be fixed in a
following commit.
With this patch loading glyphs from different faces from different
threads doesn't immediately crash in the autohinting loader code.
Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1164941
* src/autofit/afloader.c (af_loader_init): Pass
`AF_Loader' and `FT_Memory' instead of `AF_Module' as arguments.
(af_loader_reset, af_loader_load_glyph): Also pass `loader' as
argument.
(af_loader_done): Use `AF_Loader' instead of `AF_Module' as
argument.
* src/autofit/afmodule.c (af_autofitter_init): Don't call
`af_loader_init'.
(af_autofitter_done): Don't call `af_loader_done'.
(af_autofitter_load_glyph): Use a local `AF_Loader' object.
* src/autofit/afloader.h: Include `afmodule.h'.
Update prototypes.
Move typedef for `AF_Module' to...
* src/autofit/afmodule.h: ... this place.
No longer include `afloader.h'.
Assure that FreeType's internal include directories are found before
`CPPFLAGS' (which might be set by the user in the environment), and
`CPPFLAGS' before `CFLAGS'.
* builds/freetype.mk (FT_CFLAGS): Don't add `INCLUDE_FLAGS'.
(FT_COMPILE): Make this a special variable for compiling only the
files handled in `freetype.mk'.
(.c.$O): Removed, unused.
* src/*/rules.mk (*_COMPILE): Fix order of include directories.
Based on a patch from Behdad.
* src/truetype/ttinterp.c (DO_*): Expand macros into corresponding
`Ins_*' functions.
(TT_RunIns): Replace `DO_*' macros with `Ins_*' function calls.
(ARRAY_BOUND_ERROR): Remove second definition, which is no longer
needed.
(Ins_SVTCA, Ins_SPVTCA, Ins_SFVTCA): Replaced with...
(Ins_SxyTCA): New function.
This is a follow-up patch.
* src/truetype/ttinterp.c, src/truetype/ttinterp.h
[TT_CONFIG_OPTION_STATIC_INTERPRETER,
TT_CONFIG_OPTION_STATIC_RASTER]: Remove macros and related code.
Apparently, BSD tar isn't capable yet of handling POSIX-1.2001
(contrary to GNU tar), so force the POSIX-1.1988 format.
Problem reported by Stephen Fisher <sfisher@SDF.ORG>.
Some prototypes in ftvalid.h use `valid' for the variables
typed as FT_Validator. Their implementations in src/base/
ftobjs.c and utilizations in src/sfnt/ttcmap.c do similar.
Some macros in otvcommn.h assume the exist of the variable
`valid' typed as OTV_Validator in the caller.
Mixing these two conventions cause invalid pointer conversion
and unexpected SEGV in longjmp. To prevent it, all variables
typed as OTV_Validator are renamed to `otvalid'.
* src/otvalid/otvcommn.h: Replace `valid' by `otvalid'.
* src/otvalid/{otvcommn.c, otvbase.c, otvgdef.c, otvgpos.c,
otvgsub.c, otvjstf.c, otvmath.c}: Replace `valid' by `otvalid'
if it is typed as OTV_Validator.
Work around `features' of X11's `pcfWriteFont' and `pcfReadFont'
functions. Since the PCF format doesn't have an official
specification, we have to exactly follow these functions' behaviour.
The problem was unveiled with a patch from 2014-11-06, fixing issue #43547.
* src/pcf/pcfread.c (pcf_read_TOC): Don't check table size for last
element. Instead, assign real size.
=========================
Tag sources with `VER-2-5-4'.
* docs/VERSION.DLL: Update documentation and bump version number to
2.5.4.
* README, Jamfile (RefDoc), builds/windows/vc2005/freetype.vcproj,
builds/windows/vc2005/index.html,
builds/windows/vc2008/freetype.vcproj,
builds/windows/vc2008/index.html,
builds/windows/vc2010/freetype.vcxproj,
builds/windows/vc2010/index.html,
builds/windows/visualc/freetype.dsp,
builds/windows/visualc/freetype.vcproj,
builds/windows/visualc/index.html,
builds/windows/visualce/freetype.dsp,
builds/windows/visualce/freetype.vcproj,
builds/windows/visualce/index.html,
builds/wince/vc2005-ce/freetype.vcproj,
builds/wince/vc2005-ce/index.html,
builds/wince/vc2008-ce/freetype.vcproj,
builds/wince/vc2008-ce/index.html: s/2.5.3/2.5.4/, s/253/254/.
* include/freetype/freetype.h (FREETYPE_PATCH): Set to 4.
* builds/unix/configure.raw (version_info): Set to 17:3:11.
* CMakeLists.txt (VERSION_PATCH): Set to 4.
* docs/CHANGES: Updated.
* src/cff/cf2hints.c (cf2_hintmap_map): After the fix for Savannah
bug #43661, the test font `...aspartam.otf' still triggers an
FT_ASSERT. Since hintmap still works with count==0, ...
(cf2_glyphpath_lineTo, cf2_glyphpath_curveTo): ... add that term to
suppress the assert.
