When iterating over the cvt tuples and reading in the points it is necessary
to set all of `localpoints`, `points`, and `point_count` in all cases. The
existing code did not reset `localpoints` to `NULL` when there were no
private point numbers. If the previous tuple did have private point numbers
and set `localpoints` to `ALL_POINTS` this would not be cleared and the
wrong branch would be taken later, leading to possible heap buffer overflow.
* src/truetype/ttgxvar.c (tt_face_vary_cvt): Reset `localpoints` to `NULL`
when it isn't valid.
Fixes: https://crbug.com/1284742
* src/truetype/ttobjs.h (TT_SizeRec): Add `widthp` for the hdmx
widths.
* src/truetype/ttobjs.c (tt_size_reset): Initialize `widthp` even
though it might never be used by the interpreter.
* src/truetype/ttgload.c (tt_loader_init): Avoid repeated searches
in the hdmx table.
This fixes fall-out from 7809007a5b, where the composite
accents were no longer hinted.
* src/truetype/ttgload.c (ttloader_init): Move the IUP-called flag
initialization from here...
* src/truetype/ttinterp.c (TT_Run_Context): ... to here.
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.
This simply shortcuts the glyph loading if FT_LOAD_ADVANCE_ONLY
is specified by FT_Get_Advances and the `hdmx` data are located.
Particularly, the classic v35 interpreter or "verified" ClearType
fonts might see 100x speed up in retrieving the hdmx cache.
* src/truetype/ttgload.c (TT_Load_Glyph): Insert the shortcut.
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.
`TT_RunIns` is too busy to deal with subpixel flags. It is better
to set them in `tt_loader_init`, which is executed before each
glyph program.
* src/truetype/ttinterp.c (TT_RunIns): Move the flag setting from
here...
* src/truetype/ttgload.c (tt_loader_init): ... to here.
* src/truetype/ttinterp.c (Ins_INSTCTRL): Limit its global effects
to the CVT program and local effects to the glyph program.
This also fixes an Infinality buglet. The `ignore_x_mode` should be
locally unset by the glyph program.
The `hdmx` table is optional and can be safely rejected without
an error if it does not follow specifications. The record size
must be equal to the number of glyphs + 2 + 32-bit padding.
* src/truetype/ttpload.c (tt_face_load_hdmx): Thoroughly check
the record size and improve tracing.
* src/truetype/ttgxvar.c (ft_var_load_item_variation_store):
s/shortDeltaCount/wordDeltaCount/ (as done in the specification, too).
Recognize new format and reject it for now.
This is in preparation for implementing `DeltaSetIndexMap` format 1, which
is used by `COLR` v1 tables, and which allows 32bit indices.
https://docs.microsoft.com/en-us/typography/opentype/otspec190/delta/otvarcommonformats_delta.html
* src/truetype/ttgxvar.h (GX_DeltaSetIdxMapRec): Change type of `mapCount`
to `FT_ULong`.
* src/truetype/ttgxvar.c (ft_var_load_delta_set_index_mapping): Add argument
for passing the table size; update caller.
Implement new format.
Based on a patch from metarutaiga (MR !106).
* src/truetype/ttobjs.c (tt_skip_pdffont_random_tag,
tt_check_trickyness_family, tt_synth_sfnt_checksum, tt_get_sfnt_checksum,
tt_check_trickyness_sfnt_ids, tt_check_trickyness): Put functions into a
`TT_USE_BYTECODE_INTERPRETER` block.
(tt_face_init): Put trickyness checks into a `TT_USE_BYTECODE_INTERPRETER`
block.
Fixes#1111.
* src/truetype/ttgxvar.c (ft_var_readpackeddeltas, ft_var_load_avar,
ft_var_load_item_variation_store, ft_var_load_gvar): Use FT_QNEW_ARRAY
if memory immediately initialized or discarded otherwise.
* src/truetype/ttgxvar (ft_var_readpackeddeltas): Don't expect the number of
bytes used to encode the deltas to be higher than the number of encoded
values. The specification allows a very compact encoding; for example, a
list of 200 zeros can be encoded with just a couple of bytes.
We now count the consumed bytes to make sure to not read more than expected.
* src/truetype/ttgxvar (tt_face_vary_cvt): Function
`ft_var_readpackedpoints`, when it returns `ALL_POINTS`, also sets
`point_count` to value 0. However, the CVAR code was incorrectly expecting
that `point_count` would be set to match the length of the CVT table.
When a different hinting mode from the current is selected, the `prep` table
must be re-executed with the new mode. After this happens the context must
be re-loaded in preparation for the glyph program to be run.
Fixes#1104.
* truetype/ttgload.c (tt_loader_init): Add call to `TT_Load_Context`.
* src/truetype/ttobjs.c (tt_check_trickyness_family): For the case
that the beginning part of a long tricky family name is already
registered as another tricky family name, no need to double-check
the longer one. Such long tricky family names are removed from
the `trick_names'.
* src/truetype/ttobjs.c (tt_skip_pdffont_random_tag):
New function to skip the randomization tag in the names of the
fonts embedded in a PDF. It is used by tt_check_trickyness_family(),
to keep from mistaking "DLC" in the randomization tag as a
tricky font name. See discussion in:
https://lists.nongnu.org/archive/html/freetype-devel/2021-02/msg00002.html
For technical detail about the randomization tag, please find
PDF Reference 5.5.3 "Font Subsets". Thanks to Justyna Wawrzynska
for pointing out the issue caused by the randomization tag.
Thanks to Ting717 for providing sample PDF. Fixes#1087.
* src/truetype/ttobjs.c (tt_check_trickyness_sfnt_ids): Add
checksums for 2 tricky fonts `DFHei-Bd-WIN-HK-BF' and
`DFMing-Md-WIN-HK-BF'.
It is undefined behavior to pass `NULL` to `memcpy`. `coords' is
passed to `memcpy` but `TT_Get_MM_Blend` and `TT_Get_Var_Design`
explictly call `tt_set_mm_blend` with `coords` as `NULL`. In
addition, `TT_Set_MM_Blend` has a similar possible issue.
In commit 531d463aed
[truetype] Allocate TT_ExecContext in TT_Size instead of TT_Driver.
the `TT_ExecContext` was moved from being on the driver to being on the size
to make it easier to use FreeType in a multi-threaded environment. However,
the documentation for `TT_New_Context` was not updated and still reflects
the old behavior and parameter list.
This change updates `TT_New_Context` documentation to reflect the current
parameters and usage.
`FDEF` instructions are specified as allowed only in 'prep' or
'fpgm'. FreeType has attempted to prevent their use in the glyph
program, but they were still allowed in glyph programs if defined in
a function defined in 'prep' or 'fpgm' and called from the glyph
program.
Similarly, `IDEF` instructions are specified not to be able to
modify any existing instruction. FreeType has attempted to prevent
their use in the glyph program, but they can still be used like
`FDEF`.
This change stores the initial bytecode range type and disallows the
use of `FDEF` and `IDEF` while running the glyph program.
Most other state is copied from the `TT_Size` into the execution
context. However, it is possible for a glyph program to use `WS` to
write to the storage area or `WCVTP`, `WCVTF`, and `DELTAC[123]` to
write to the control value table.
Allowing any change to the global state from the glyph program is
problematic as the outlines of any given glyph may change based on
the order the glyphs are loaded or even how many times they are
loaded. There exist fonts that write to the storage area or the
control value table in the glyph program, so their use should not be
an error.
Possible solutions to using these in the glyph program are
* ignore the writes;
* value-level copy on write, discard modified values when finished;
* array-level copy on write, discard the copy when finished;
* array-level copy up-front.
Ignoring the writes may break otherwise good uses. A full copy
up-front was implemented, but was quite heavy as even well behaved
fonts required a full copy and the memory management that goes along
with it. Value-level copy on write could use less memory but
requires a great deal more record keeping and complexity. This
change implements array-level copy on write. If any attempt is made
to write to the control value table or the storage area when the
initial bytecode range was in a glyph program, the relevant array
will be copied to a designated storage area and the copy used for
the rest of the glyph program's execution.
* src/truetype/ttinterp.h (TT_ExecContextRec): New fields
`iniRange`, `glyfCvtSize`, `glyfCvt`, `origCvt`, `glyfStoreSize`,
`glyfStorage`, and `origStorage`.
* src/truetype/ttinterp.c (Modify_CVT_Check): New function to handle
`exc->glyfCvt`.
(Write_CVT, Write_CVT_Stretched, Move_CVT, Move_CVT_Stretched): Use
it.
(Ins_WS): Handle `exc->glyfStorage`.
(Ins_FDEF, Ins_IDEF): Updated.
(TT_RunIns): Updated.
(TT_Done_Context): Free 'glyf' CVT working and storage area.
(TT_Load_Context): Fix/add casts.
* src/truetype/ttgload.c (TT_Load_Simple_Glyph): Fix cast.
This ensures good logging output, with all lines having a proper
prefix (if requested).
This is a continuation of a similar patch from 2020-12-02, which
missed some locations.
Werner Lemberg