Re: [ft-devel] [PATCH resend 2/2] Improve FT_Outline_Embolden for the unintended artifacts problem (#45596).

[Byeongsik Jeon]

On Thu, 4 Oct 2018 22:34:56 -0400, Alexei Podtelezhnikov <address@hidden> 
wrote:>>> +        /* The large shift value creates a cross point, which appears
>>> +           as one of the artifacts. The shift value limitation inhibits
>>> +           the occurrence of artifacts. */
>>> +        shift.x = FT_MAX( FT_MIN( shift.x, strength.x ), -strength.x );
>>> +        shift.y = FT_MAX( FT_MIN( shift.y, strength.y ), -strength.y );
>>> +
>>
>> Maybe, it is threshold on the determinant. This inhibits the sarpen corner, 
and
>> the cross point artifacts.
>
> Hmm. This is not invariant with respect to rotation. It will work
> differently for along the axes and along 45 degree line. It is also
> extremely restrictive: the shift magnitude (Euclidean) is always
> larger than strength for any (even obtuse) angle. So even obtuse
> angles are subject to this restriction sometimes. I wonder if this is
> the reason you had to compensate with larger strengths in the second
> patch. Have you tried limiting the shift to double or triple the
> strength?
>
The Embolden function of the resended patch has not changed from the original. I 
just wanted to start this discussion on the new thread.

I'm aware of the problem you're talking about. It appears in the "/" letter.

bauhaus_256px_1_gedit_ftsynth_patched.png
bauhaus_256px_2_gedit_ftsynth+shift_limit_patched.png

When you compare them, you can see that the diagonal stem thickness changes in 
the letters "%" and "4". However, the final result is the same as Windows, so no 
further processing was done.

I have the idea of ​​"shift limit code" being separated from artifact like "X" 
and normal "/" case. But as I wrote above, I need to investigate MS Windows, so 
I want to add it to another patch.



On Thu, 4 Oct 2018 22:51:33 -0400, Alexei Podtelezhnikov <address@hidden> wrote:
> I can also see that after all set and done the glyph is much less
> emboldened. You could have just used less strength with the original
> algorithm and achieved similar results. Again it is important to
> achieve fewer artifacts with the*same*  stem thickness.

If you look at the fetsynth patch, you can see that the strength value has been 
modified. I have made it an important goal to match with Windows looks. The 
original code is divided by 24 so it has a thicker stem. But it doesn't match 
Windows looks.

+    /* the value that matches the MS Windows embolden looks.
+       the larger strength value, the more unintended artifacts increase.
+       using the integer pixel strength inhibits the blurred outlines.
+     */
+    ppem = face->size->metrics.y_ppem;
+    ystr = (( ppem - 1 ) / 50 ) << 6;
+    xstr = ystr + 64;


bauhaus_256px_1_gedit_ftsynth_patched.png

This is the result of reducing strength only in the original algorithm. It's 
only a reduction in the size of the artifact, but it still occurs. Thickness( 
strength) is not the main cause of its occurrence.

Please look at the description of the patch that was resended.

> The "forward-backward mixed straight segment" are particularly important.
> Because their shift vectors are in the opposite direction, they produce a
> prominent artifact.

I've got two goals.
- Match with Windows as much as possible
- Unintended artifact suppression.

The improved code seems to have achieved these two goals, and it's easy to 
accept new ideas because the algorithms are easy.

Thanks.