After the next release we are going to remove the code completely.
* devel/ftoption.h, include/freetype/config/ftoption.h
(FT_CONFIG_OPTION_OLD_INTERNALS): Comment out.
* docs/CHANGES: Document it.
The recent optimizations of CORDIC iterations drastically reduce
the expansion factor. The vector components with MSB of 29 are now
safe from overflow.
* src/base/fttrigon.c (FT_TRIG_SAFE_MSB): New macro.
(ft_trig_prenorm): Use it and remove dead code.
* src/base/fttrigon.c: Document the algorithm in a large comment.
(FT_TRIG_COSCALE): Remove macro.
(FT_Tan: Use `FT_TRIG_SCALE' instead.
(FT_Cos, FT_Vector_Unit): Ditto and round the return values.
After we get within 45 degrees by means of true 90-degree rotations,
we can remove initial 45-degree CORDIC iteration and start from
atan(1/2) pseudorotation, reducing expansion factor thereby.
* src/base/fttrigon.c (FT_TRIG_SCALE, FT_TRIG_COSCALE): Update macros.
(ft_trig_pseudo_rotate, ft_trig_pseudo_polarize): Update.
* src/tools/cordic.py: Bring up to date with trigonometric core.
* docs/CHANGES: Old typo.
Problem reported by Robin Watts <robin.watts@artifex.com>.
* src/base/ftoutln.c (FT_Outline_New_Internal): Ensure that
`numContours' and `numPoints' fit into FT_Outline's `n_points' and
`n_contours', respectively.
FreeType used to rely on a 24-step iteration CORDIC algorithm to
calculate trigonometric functions and rotate vectors. It turns out
that once the vector is in the right half-plane, the initial rotation
by 63 degrees is not necessary. The algorithm is perfectly capable
to converge to any angle starting from the second 45 degree rotation.
This patch removes the first rotation and makes it a 23-step CORDIC
algorithm.
* src/base/fttrigon.c (FT_TRIG_SCALE, FT_TRIG_COSCALE): Update macro
values.
(ft_trig_pseudo_rotate, ft_trig_pseudo_polarize): Remove initial
rotation.
* include/freetype/internal/ftserv.h (FT_SERVICE_UNAVAILABLE): Use
`logical not' operator instead of negation. The idea is that `~'
returns exactly the data type enforced by the cast to a pointer (be
it 32bit or 64bit or whatever), while a negative integer has not
this flexibility.
* src/cache/ftccmap.c (FTC_CMAP_UNKNOWN): Ditto.
* src/truetype/ttgxvar.c (ALL_POINTS, TT_Get_MM_Var): Ditto.
* src/type/t1load.c (T1_Get_MM_Var): Ditto.
(parse_blend_axis_types): Use cast.
* src/bdf/bdflib.c (_bdf_readstream): Use cast.
Since the initial commit (ebe85f59) the value of FT_TRIG_SCALE has
always been slightly less than the correct value, which has been
given in the comment as a hexadecimal. As a result, vector lengths
were underestimated and rotated vectors were shortened.
The dot product between freeVector and projVector or cosine of
the angle between these FT_F2Dot14 unit vectors used to be scaled up
by 4 and routinely occupied 32 bits in an FT_Long field F_dot_P.
This patch scales the value down by 2^14 instead, which simplifies
its use throughout the bytecode interpreter.
This does not lead to the loss of precision because the lower bits
are unreliable anyway. Consider two unit vectors (1,0) and (.6,.8)
for which the true value of F_dot_P is .6 * 0x40000000 = 0x26666666.
These vectors are stored as (0x4000,0) and (0x2666,0x3333) after
rounding and F_dot_P is assigned 0x26660000. The lower bits were
already lost while rounding the unit vector components.
Besides code simplification, this change can lead to better
performance when FT_MulDiv with the scaled-down F_dot_P is less
likely to use the costly 64-bit path. We are not changing the type
of F_dot_P to FT_F2Dot14 at this point.
* src/truetype/ttinterp.c (Compute_Funcs): Scale F_dot_P down by 14
bits and modify its use accordingly.
(Direct_Move, Direct_Move_Orig, Compute_Point_Displacement): Modify
the use of F_dot_P field.
* src/truetype/ttobjs.c (tt_size_run_fpgm): Change arbitrary
assignment of F_dot_P to its theoretical maximum in case we decide
to scale back its type later.
* src/truetype/ttinterp.c (TT_DivFix14): New macro.
(Normalize): Use it here.
(Current_Ratio): Use TT_MulFix14 instead of FT_MulDiv.
(Ins_SHPIX): Cancel out two TT_MulFix14 calls.
This is Savannah bug #37856.
* src/pshinter/pshglob.c (psh_calc_max_height): New function.
(psh_globals_new): Use it to limit BlueScale value to
`1 / max_of_blue_zone_heights'.
Problem reported by Del Merritt <del@alum.mit.edu>.
* builds/unix/configure.raw <cpp computation of bit length>: Don't
remove existing FreeType configuration files.
Werner Lemberg