RE: [ft] Glitchy stroker output

[Stephan T. Lavavej]

> For testing purposes, I've slightly altered your program so that only
> one glyph of zeroes_three.ttf is rendered, the dot glyph.  To make the
> effects really visible, I've also set nominal_pixel_height to 96 and
> real_26_6_border_radius to 16*64.  Attached is the resulting PNG.
> However, after the call of FT_Glyph_Stroke, the returned FT_Outline
> structure looks just fine (see the attached PDF as created with
> MetaPost).

That narrows down what could be causing this problem, thanks!

> It seems that the problem occurs later in your program, during
> the rendering process: Probably an initialization bug, or a too-
> small array?

My "arrays" are std::vectors, which expand automatically, so they're very
unlikely to be the problem.


Following what you've done, I've further simplified my repro:

http://stl.nuwen.net/pub/freetype/repro2.cc
http://stl.nuwen.net/pub/freetype/output_new.png

This uses a real_26_6_border_radius of 30 * 64, which significantly detaches
the border from the core glyph.

The detachment (which happens only for extremely thick borders, much thicker
than is necessary to cause visible right-side glitching) appears to be
caused by self-intersection of the border outline.  With repro2.cc, which
makes the border and core overlap visible, I tried gradually increasing the
border radius, and watched it self-intersect before detaching.  I'm not
/very/ concerned about the detachment; I'm much more concerned about the
right-side glitching.

The right-side glitching appears to be a separate effect, and unrelated to
my rendering process. The data given by FT_Outline_Render() to my
span_func() is being accurately rendered to the BMP (or to the texture, in
my original code). To demonstrate this, repro2.cc's span_func() prints out
each span that it receives.  Because the border radius of 30 * 64 is so
extreme, the right-side glitching can actually be observed from the spans
themselves.

First, look at the Core spans.  They range from y = -2 to y = 12.  As the
glyph is a circle, the widest part is at roughly y = 5.  There are 3 Core
spans for that row:

  Core | coverage 253 | y   5 | x [  3,   3]
  Core | coverage 255 | y   5 | x [  4,  16]
  Core | coverage 252 | y   5 | x [ 17,  17]

The core glyph's right edge covers x = 17.

Now, consider the border.  If the outline is correct, it should be a ring
(given the detachment).  Therefore, its spans for the row y = 5 should have
x-coordinates less than 3, and greater than 17, and should extend for a
while (visually, about 14 pixels). Instead, the spans that we get are:

Border | coverage 254 | y   5 | x [-27, -27]
Border | coverage 255 | y   5 | x [-26, -13]
Border | coverage   3 | y   5 | x [-12, -12]
Border | coverage   1 | y   5 | x [ 21,  21]

This *exactly* matches the rendered image; the left part is fine, while the
right part is cut off (and not even in the correct position; x = 21 is too
close to the glyph).

Since you've determined that the border outline is valid, and I've
determined that FT_Outline_Render() is returning bogus spans, either
FT_Outline_Render() is buggy, or I'm calling it incorrectly (but I don't see
how, and it works for the core glyph and the other sides of the border).

Also - I tried this with verdana.ttf from Windows and still got the
glitching, so we can rule out zeroes_three.ttf being busted somehow.

Thanks,
Stephan T. Lavavej