Without this patch, only the dummy and cjk autohinter modules get
them (since they copy the whole scaler object).
* src/autofit/aflatin.c (af_latin_metrics_scale),
src/autofit/aflatin2.c (af_latin2_metrics_scale): Implement it.
* builds/unix/configure.raw: Check `-ansi' flag works even if gcc
is used. Bionic libc headers for Android lose the consistency
when they are parsed with __STDC_VERSION__ older than 199901L or
__STRICT_ANSI__.
Based on the patch given in the bug report.
* src/type1/t1load.c (IS_INCREMENTAL): New macro.
(read_binary_data): Add parameter `incremental'.
Update all callers using `IS_INCREMENTAL'.
This was quite a subtle bug which accidentally showed up with glyph
`afii10023' of arial.ttf (version 2.76). This glyph is a composite;
the first component, `E', has an advance width of 1366 font units,
while the advance width of the composite itself (which looks like
uppercase `E' with dieresis) is 1367 font units. I think this is
actually a bug in the font itself, because there is no reason that
this glyph has not the same width as uppercase `E' without the
dieresis. Anyway, it helped identify this problem.
Using the TrueType hinter, the correct value (1367) of `afii10023'
was returned, but the autohinter mysteriously returned 1366.
Digging in the code showed that the autohinter recursively calls
FT_Load_Glyph to load the glyph, adding the FT_LOAD_NO_SCALE load
flag. However, the `linearHoriAdvance' field is still returned as a
scaled value. To avoid scaling twice, the old code in autofit reset
`linearHoriAdvance', using the `horiAdvance' field. This seemed to
work since FT_LOAD_NO_SCALE was in use, but it failed actually,
because `horiAdvance' is defined as the distance of the first
subglyph's phantom points, which in turn are initialized using the
advance width of the first subglyph. And as the given example
shows, these widths can differ.
* src/autofit/afloader.c (af_loader_load_g): Temporarily set
FT_LOAD_LINEAR_DESIGN while calling FT_Load_Glyph to get unscaled
values for the linear advance widths.
* src/truetype/ttinterp.c (DO_SSW): SSW *does* use font units. For
verification, it took some time to find a font which actually uses
this instruction.
For some divisions, we use casts to 32bit entities. Always guard
against division by zero with these casts also.
* src/base/ftcalc.c (ft_div64by32): Remove redundant cast.
(FT_MulDiv, FT_MulDiv_No_Round): Add 32bit cast.
(FT_DivFix): Add 32bit cast (this omission triggered the bug).
* src/psaux/afmparse.c (afm_parse_track_kern): Don't inverse sign
for `min_kern'. It is indeed quite common that track kerning
*increases* spacing for very small sizes.
If in function `skip_spaces' the routine `skip_comment' comes to the
end of buffer, `cur' is still increased by one, so we need to check
for `p >= limit' and not `p == limit'.
* src/psaux/psconv.c (PS_Conv_Strtol, PS_Conv_ToFixed,
PS_Conv_ASCIIHexDecode, PS_Conv_EexecDecode): Fix boundary checking.
* src/truetype/ttinterp.c (Ins_MIRP): Typo, present since ages. The
code is now in sync with the other operators (e.g. MSIRP) which
modify twilight points.
* src/bdf/bdflib.c (_bdf_list_ensure): Bring code in sync with
comment before `_bdf_list_split', this is, really allocate at least
five `field' elements.
* src/bdf/bdflib.c (_bdf_parse_glyphs) <DWIDTH, BBX>: Abort if
_BDF_ENCODING isn't set. We need this because access to the `glyph'
variable might be undefined otherwise.
* src/smooth/ftsmooth.c (ft_smooth_render_generic): Use `FT_Pos'
instead of `FT_UInt' for some variables and update comparisons
accordingly. A detailed analysis can be found in the bug report.
Werner Lemberg