Hi Fellows, Collègue J-M_L,
The issue still annoys some, like … a pebble in a shoe.
What is the nature of the problem? I mean … technical one.
Font glyphs are defined by a collection of (poly)line segments and Bezier curves with point coordinates limited to a grid of limited size (16x16, 32x32, …).
The underlying algorithms must be very efficient computationally and in terms of memory utilization.
The right image of the foundation post is an excellent example of it.
The Bezier curves mentioned can be quadratic and cubic types … with an efficiency trick implemented. When two quadratic representations are codded in succession… they are together considered as a cubic type.
Looking at the right image, it seems that F360 renders two quadratic Beziers separately instead of performing the necessary trick.
Here is a way to do it: extracted from FreeType code depository: https://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/src/base/ftoutln.c
The following excerpt of the code and its implementation by TF360 … should throw the pebble away.
/* check first point to determine origin */
if ( tag == FT_CURVE_TAG_CONIC )
{
/* first point is conic control. Yes, this happens. */
if ( FT_CURVE_TAG( outline->tags[last] ) == FT_CURVE_TAG_ON )
{
/* start at last point if it is on the curve */
v_start = v_last;
limit--;
}
else
{
/* if both first and last points are conic, */
/* start at their middle and record its position */
/* for closure */
v_start.x = ( v_start.x + v_last.x ) / 2;
v_start.y = ( v_start.y + v_last.y ) / 2;
/* v_last = v_start; */
}
point--;
tags--;
}
... and by looking at the code simplicity ... the implementation should be brisk&quick, shouldn't it, Mr Strater :).
Regards
MichaelT
MichaelT
